remember what the GoF book says, favour abstraction over inheritance I believe the statement is "favor COMPOSITION over inheritance." Abstraction and inheritance really do not have much/anything in common. Using composition as an alternative to inheritance
can help prevent your inheritance trees from becoming too deep and complex to support changes over time. Smoke
Thona takes a lot of heat on these boards for some of his posts - and rightly so in some/many situations. However, I did not experience any of that nonsense when I was evaluating his product and asking questions about its features and use. Although you may
not like the "personality" that Thona presents on these boards, keep in mind that this is not his customer base/support forum and not necessarily how he deals with his customers. While that may be true, I think you have to be the face of your company
at all times, regardless of where you are, who you are talking to or what you are doing. Everything you do reflects on your company and you have to realize that. The fact that he so matter of factly states he doesn't care about what anyone thinks of him I
believe says it all. You have to take care of your customers, and likely he does in the context of supporting his product, but it sure doesn't give someone like me looking for a product much confidence that my $499-999 would be well spent there. Don't get
me wrong, I'm sure its a great product, but I'm betting one of the other three will do as much as I need and Frans, Paul and Eric seem very reasonable to deal with if I do have a problem or question.
I agree that Thona could foster a better image on these forums by candy coating more posts. But I don't blame people for not doing this, as long as they understand the consequences. In this case it appears that he is losing a "potential" customer. I definitely
agree with you that most likely another mapper will work fine for your product. It's just that IF you needed some advanced features that EntityBroker provides (COM+ Transactions?) you probably shouldn't automatically rule it out since it's one of the few that
provides them.
2 jammycakes >>>One thing I'm a bit unsure about though with NHibernate is its ability to handle lazy loading of child collections. As far as I can tell this is one of the things that depends on Aspect# -- is that correct? Lazy loading of one-to many is supported
in NHibernate. It is many-to-one and many-to-many lazy loading that is not supported yet. Actually There's version of NHibernate in CVS that is using dynamic proxies and supports lazy loading of all kinds of collections. Ask Tijn. He is using proxy version
and says he has no problems with it. I will switch to it if need arises, but so far i'll wait until they move proxies to main branch.
Vagif, "Once upon a time in far far java land..." :-) What a nice fairytale! "Actually you Mats will be able to tell me more about it. SInce you are an ORM vendor. And I recal you said something about many people hesitating use of your tool exactly for this
reason. Can you provide more details ? How many times you heard that requirement (no interfaces on domain model please!) ? " Well, people don't like making their projects dependent on me not catching the flu or even being run over by a bus, to put things in
a nutshell. The more "tie-in" to my framework, be it via interfaces, base classes or just some special way you have to develop, the worse. Even if being open source alleviates this concern, O/R Mappers often contain a line or two of code, if you catch my drift...when
the Project suddenly crashes 2 days before dealine, it can be more comforting if the bug is in /this/ large pile of code that /you/ wrote and are familiar with rather than being in /that/ large pile of code that you just downloaded, trusted, and will now have
to try to debug even though you're totally unfamiliar with it... But as Frans has often done a great job of pointing out in the most reasonable manner: We /can't/ go around developing everything ourselves. I won't even list all the arguments for why not, because
A) Frans does it better, and B) I think we all know already? :-) Nevertheless, O/R mappers are complicated. They are bound to contain bugs. So while all the arguments for why, in the end, downloading/purchasing and using an O/R mapper will make sense, that
doesn't mean that the counter-arguments, such as the one I described above, just magically go away. Rather, as you decide on which O/R Mapper to use, it is quite understandable if you still look for one that would seem to carry "less risk". And how the h*ll
does one determine that, you may ask. To which I reply: Quite. It's not easy. This is where all sorts of aspects start to creep in: - Project size: Should I go with a simpler O/R Mapper using a smaller code base? Less code ought to mean both less bugs as well
as less code for me to debug when the sh*t hits the fan...on the other hand, If I follow that logic to it's extreme, I'll end up with an O/R Mapper consisting of just one method containing one line of code throwing a NotImplementedException...so, there must
be some balance somewhere I should look for. - Tie-in: Will it be easy for me to swap to another O/R Mapper if this one turns out in the end to just not work? And /which/ other O/R Mappers, exactly, will it be easy for me to swap to from this O/R Mapper? Tie-in
is where things like requirements for framework interfaces and base classes comes in, but things like how the query system looks are also part of this deal, as well as special ways of working with your persistent objects that are required by the O/R Mapper.
- Support/Community: /When/ (and I do say when, not if) I sit there two days before my deadline, debugging the O/R Mapper, will I be completely on my own or will there be any online support forums or communities around the O/R Mapper that can help me? Documentation
is of course another important aspect here. Plus of course, many other things. Again, picking O/R Mapper is not easy. What I'm trying to say with this post is that I think people often ask things like "Do you require implementing any special interfaces" not
because it is a technical requirement from their project that my O/R Mapper doesn't, but because it will give them some indication as to the amount of tie-in they can expect. So, the direct answer to your question is: I get asked this question a lot! But often
it turns out that it wasn't critical if they come to the conclusion that the amount of tie-in could be balanced by the amount of functionality or performance that the tie-in would offer. I'm not in the habit of implementing unecessary tie-ins in my product
in order to gain some sort of competitive advantage. Frankly, I've never felt suspected of this either, by people asking me about the level of tie-in in my products. And I feel I can say that I'm pretty darn convinced none of the other O/R Mapping vendors
do such things either. And one good reason for this is that, unless you have a really serious monopoly, creating tie-in to keep customers /isn't/ a very smart move because people have learned to be on the look-out for tie-ins (perhaps almost paranoically so,
at times) and as soon as they have a choice, they go for the alternatives requiring less tie-in. So, I'm not in the habit of implementing unecessary tie-ins in my product - but as of NPersist and ObjectMapper, I've also decided not to go down the road of avoiding
tie-in at all cost! It was just this mistake that had me maintaining a code generator (Pragmatier) which would spit out code that should have been put in a reusable framework - something for which Thomas would refer to me as an idiot, and today I have to agree
that, well, I was... This means that, while I resist requiring tie-in as far as I can, I'll still prefer a bit of tie-in to a solution that just isn't reasonable. The Pragmatier code generation is one such example. And, I have to say, looping through all loaded
objects and comparing each one with it's original copy to see which ones are dirty is another... Summing up, I think it is 100% reasonable to be wary of tie-in, but that you should also look at /why/ the tie-in is there and see if maybe it is motivated. /Mats
Vagif: Thanks, that clears up a bit of confusion that I had. Smoke: > I believe the statement is "favor COMPOSITION over inheritance." You're right, it is. And I do know the difference. And it was composition I was thinking of. And I have a copy of the GoF
book right here on my desk. This must be a case of YABHD (yet another bad hair day)...
rsmoke21, "It's just that IF you needed some advanced features that EntityBroker provides (COM+ Transactions?) you probably shouldn't automatically rule it out since it's one of the few that provides them." All O/R Mappers support Distributed (COM+/EnterpriseServices)
Transactions. You don't have to do anything special with your Domain/Entity objects in order to let them support Distributed Transactions, except signing them with a strong name. That has nothing to do with which O/R Mapper you choose. /Mats
> -------------------------- > Re: Your favorite O/R Mapper? by matshelander rsmoke21, > "It's just that IF you needed some advanced features that > EntityBroker provides (COM+ Transactions?) you probably > shouldn't automatically rule it out since it's one
of the few > that provides them." > > All O/R Mappers support Distributed (COM+/EnterpriseServices) > Transactions. You don't have to do anything special with your > Domain/Entity objects in order to let them support > Distributed Transactions, except signing
them with a strong > name. That has not hing to do with which O/R Mapper you choose. No, this is not true. The COM+ transaction has to flow through the ado.net connection created by the O/R mapper engine. This is not the case if the connection is created by
a class which is not derived from servicedcomponent. So you'll then end up with an ADO.NET transaction which will be committed, but will not be rolled back when the COM+ transaction is rolled back. It's also not useful to use an ADO.NET transaction over a
connection which is controlled by COM+. So the mapper has to contain code to support this, which is why not that much mappers support it through and through for 100% :). I use a serviced component derived class with a factory for the connection in selfservicing
(entity.Save() paradigm) and a com+ wrapper for adapter which provides the connection controlled by COM+ for the adapter paradigm (adapter.SaveEntity(entity)).
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
2 Mats >>>So, the direct answer to your question is: I get asked this question a lot! >>>This means that, while I resist requiring tie-in as far as I can, I'll still prefer a bit of tie-in to a solution that just isn't reasonable. Yes, it is not easy. I wish
you'd find a solution that will allow you to have full control over persisted objects and at the same time do not tie in your customers with interfaces. That's why I suggested using Aspect#. Unfortunately AOP in dotnet is just starting and is not as mature
as in java. I still do not know if you will be able to access private fields from within aspect# mixins. Btw NHibernate have ways to mark objects dirty. I do not know how do they do that without any interfaces on domain model objects at all !.
rsmoke21
Contributor
3931 Points
792 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 01:03 PM|LINK
skiloff
Member
30 Points
6 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 01:48 PM|LINK
rsmoke21
Contributor
3931 Points
792 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 02:39 PM|LINK
Vagif Verdi
Member
210 Points
42 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 02:53 PM|LINK
matshelander
Member
235 Points
47 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 04:15 PM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
jammycakes
Participant
1315 Points
274 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 04:21 PM|LINK
matshelander
Member
235 Points
47 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 04:22 PM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
FransBouma
Participant
1509 Points
312 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 04:36 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
rsmoke21
Contributor
3931 Points
792 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 05:38 PM|LINK
Vagif Verdi
Member
210 Points
42 Posts
Re: Your favorite O/R Mapper?
Oct 14, 2004 07:40 PM|LINK