http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660> I switched to simple many-to-ones, where Animal would have Dog and Cat properties, and I've never been happier! In some cases this is possible (and likely, desirable), although in general such a design won't work. I.e. it is a solution working in particular cases. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment33http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment33Sat, 05 Sep 2009 06:02:53 GMT>I switched to simple many-to-ones, where Animal would have Dog and Cat properties, and I've never been happier! "Mr_Simple approves of your coding style!" Same here. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment32http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment32Fri, 04 Sep 2009 16:34:56 GMTAnd... I also surprised to hear this: "However, NH says that entities SHOULD implement Equals, GetHashCode & Equality operators, because of that exact reason.". I'm curious, what is the typical implementation? I.e. 2 things are clear for me: - Such instances are frequently used in sets & dictionaries - Thus their hash code shouldn't change - Likely, two instances with the same key must be equal Thus I see the only good implementation of these methods: they must rely only on key comparison & key hash code. If there will be anything else, you'll get mutable GetHashCode = forget about dictionaries. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment31http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment31Thu, 03 Sep 2009 11:32:38 GMTJust read this post (after reading & commenting a subsequent one about the same). I'm fully agree, such a practice is quite bad. Moreover, this is completely contradictorily to Liskov principal (in fact, you're talking about inverse principal at all!): this principal does not imply you must expose absolutely the same logic as in base type. It implies any subclass instance can replace superclass instance everywhere. But you're doing COMPLETELY INVERSE THING! Do you understand that such imagination of Liskov substitution principal makes polymorphism impossible at all? http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment30http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment30Thu, 03 Sep 2009 11:21:44 GMT@Frank Its way to easy to say "use polymorphism instead of conditionals and every problem will go away" It does solve some problems, yes.. But what if you pass the object to some custom serializer? What if you place it in a hashtable? Also, never forget that people are people and will most likely do the most quick n dirty solution they can come up with. And don't get me wrong, Im not trying to bash NHibernate or anything. I'm just saying that O/R mapping is hard enough any way for most people. So adding extra friction in terms of object comparison and identity problems will not make it easier for anyone. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment29http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment29Thu, 03 Sep 2009 07:03:49 GMTHow much of a real problem is it? Unfortunately at my current company, we engage in anemic models, and to make it even more problematic, data sets with a custom written data layer for each system. And open source libraries like NHibernate are a no-go, because too many people think they need to be in full control of everything and open source is not to be trusted. But back to the question. In my very limited experience with models, I don't see why one would check what the type of the property is. The reason why one uses inheritance is to provide different behavior. Checking for a type looks like behavior at the wrong place. John Chapman seems to be spot on with his example. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment28http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment28Wed, 02 Sep 2009 21:44:36 GMThey, if you have an animal, you don't have a cat or a dog. you have an animal. you shouldn't make any decision based on the type. Instead, you should use a polymorphic solution (like the one John said, a Visitor, etc). And what about overriding methods with "new"?!!? I think all this problems will be solved once the people that uses ORMs understands the O. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment27http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment27Wed, 02 Sep 2009 20:56:46 GMTGuessing that a Cat can't be a lover of a Dog I would imagine a different implementation. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment26http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment26Wed, 02 Sep 2009 19:34:46 GMTOh,you mean the "is" check? I agree about that one, but I fail to see how Anders' (not Richard's) statement has anything to do with that. NHibernate has made a conscious decision in this matter. It serves a very real and valuable purpose. Doesn't make it "the right" decision though. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment25http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment25Wed, 02 Sep 2009 18:43:04 GMTSee Replace conditional with polymorphism. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment24http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment24Wed, 02 Sep 2009 18:09:21 GMT"And you code still violate Liskov " Why? How? http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment23http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment23Wed, 02 Sep 2009 18:07:04 GMT@Tyler >I switched to simple many-to-ones, where Animal would have Dog and Cat properties, and I've never been happier! Mr_Simple approves of your coding style! http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment22http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment22Wed, 02 Sep 2009 15:43:25 GMTThis is why I stopped using inheritance with NH a year ago. I tried using the interface proxies to get around the issues, but it never felt right having to create interfaces for my persistent classes and remember to use them only within an inheritance hierarchy. I switched to simple many-to-ones, where Animal would have Dog and Cat properties, and I've never been happier! The team understands what's going on, they can change the type of animal from cat to dog, and they don't get any of these "is it or isn't it a dog?!" issues. I think the inheritance is very well done in NH, I just don't like having to consider so many special cases. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment21http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment21Wed, 02 Sep 2009 15:21:09 GMTRoger, Yep, leaky this is a real and annoying issue. We run around this a few times trying to resolve that, but there isn't a good solution that doesn't kill the general case for the special case. However, NH says that entities SHOULD implement Equals, GetHashCode & Equality operators, because of that exact reason. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment20http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment20Wed, 02 Sep 2009 14:26:59 GMTRoger, Nope, you can't do that without hitting the actual table container the data. That affect the general case vs. the special case. And you code still violate Liskov http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment19http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment19Wed, 02 Sep 2009 14:25:05 GMTroger hibernate works with the concept of entity and 2 entity can be compared only by their id, so in your example you must compare using lover1.Animal.Id == lover2.Animal.Id or redefine Equals and the == operator to works using only the Id. conceptually the choise it's the better choise available http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment18http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment18Wed, 02 Sep 2009 14:04:48 GMThehe, I'll bite even more on this. This introduces what we called "Leaky this" problem. The actual animal instance and the ghost proxy that is assigned to the Animal property will not be the same instance. As you explained, the ghost proxy will delegate any call to the real instance. So if the Animal class would contain a method called "SetMeAsFavoriteAnimal(AnimalLover lover)" e.g. void SetMeAsFavoriteAnimal(AnimalLover lover) { lover.Animal = this; } then consider the following code: AnimalLover lover1 = LoverRepo.GetLoverById(1); AnimalLover lover2 = new AnimalLover(); lover1.Animal.SetMeAsFavoriteAnimal(lover2); if (lover1.Animal == lover2.Animal) //THIS WILL NOT EXECUTE!!! Because lover1.Animal is a ghost proxy and lover2.Animal is a real animal instance. And this kind of problems are a PAIN to find. I do understand you have chosen this approach from pragmatic reasons, but I think it is conceptually wrong. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment17http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment17Wed, 02 Sep 2009 13:57:54 GMTThat doesnt make the initial statement true. >>animalLover.Animal.Id <-- no load You could accomplish this using correct proxies also depending on how the mapping is created. If the FK from animal lover to animal contains the type descriminator then you could very well instance a ghost proxy of the correct type. Also, assigning objects of the wrong type to an association might be an optimization but it will also enable a bunch of problems. And IMO, those problems are more related to Liskov. Let's say that you'r setters of the .Animal property contains logic that makes decisions based on the type of the assigned object. e.g. set{ if (value is dog) SendEmailIfDogLacksPuppyVaccination() this.animal = value; } One can ofcourse argue about how valid that code is, but it does prove that a mapper that uses ghost proxies would break rule of least suprise and that it would potentially break pre/post conditions of your domain logic . All of the above is somewhat offtopic, I'm just trying to say that your initial statement is not true and thus you shouldnt emphasise "any" http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment16http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment16Wed, 02 Sep 2009 13:39:20 GMTRoger, Loading on property access means that you kill a bunch of very important optimizations: animalLover.Animal.Id <-- no load session.Save(new TreatmentRecord{ Animal = animalLover.Animal <-- no load }); http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment15http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment15Wed, 02 Sep 2009 13:23:18 GMToops.. try = true http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment14http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment14Wed, 02 Sep 2009 13:18:57 GMT>>Anders, >>Liskov would be rolling in her grave, if she had one What does his statements have to do with Liskov substitution? NPersist did load the related entities on property access (when using lazy load that is) And thus, we always got an object of the correct type. So your statement that this is try for all mappers is simply not correct. You eiter lazy load using ghosts, or lazy load on property or field access. (And I assume that POCO or not POCO and how to accomplish POCO is out of the scope of this post) http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment13http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment13Wed, 02 Sep 2009 13:18:14 GMT Schrödinger, That is _aweseom_ http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment12http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment12Wed, 02 Sep 2009 12:46:00 GMTno, the cat is dead when you check for it... so it must be dog http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment11http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment11Wed, 02 Sep 2009 12:39:24 GMTJohn, You will get the right behavior, absolutely! http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment10http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment10Wed, 02 Sep 2009 12:33:04 GMTOk, Let's make this more interesting. What if the base Animal had a method called ComeHere(). A cat ignores you because cats don't listen, and the dog comes. Calling that method instead of checking the type, would you get the correct polymorphic behavior? Assuming that this does behave correctly, you can work around this issue as long as you are aware of it. While using NHibernate I never used lazy loaded properties to try to avoid situations like these. It was perfectly acceptable in our application. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment9http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment9Wed, 02 Sep 2009 12:29:37 GMTNot all valid usage scenarios are classic OO. You may want to use the object for e.g. serialization or data binding using reflection (similar to how NH itself works). http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment8http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment8Wed, 02 Sep 2009 10:54:19 GMTAnders, Liskov would be rolling in her grave, if she had one http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment7http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment7Wed, 02 Sep 2009 10:27:21 GMTThis is one of the few (only?) design choices that nHibernate does wrong, imho. Alternately you could: 1. take the penalty of joining the associated table to determine the actual type of Animal when loading the AnimalLover. 2. Let the AnimalLover lazy load the animal when accessing the Animal property. Alas, nhibernate sacrifices correctness for performance. http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment6http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment6Wed, 02 Sep 2009 09:02:25 GMToops. Should have been Cat.LivesIn not Cath.LivesIn. Not sure how the wife managed to creep into my comment there.... http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment5http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment5Wed, 02 Sep 2009 08:25:58 GMTThis has been the only real problem we have been having with nHibernate. We have a parallel class hierarchy problem where we have Animal, Cat, Dog and AnimalHome, Kennel, CatBasket. Animal has a property LivesIn which is of type AnimalHome and Dog and Cat override this property with the 'new' keyword returning Kennel and CatBasket. If you try and go Cath.LivesIn you get a cast exception. We have found a work around if anyone wants to know it..... but it aint pretty! http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment4http://ayende.com/4165/challenge-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment4Wed, 02 Sep 2009 08:24:02 GMT