﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Nestor Rodriguez commented on NHibernate: Complex relationships</title><description>This challenge is an evidence of how NHibernate can deal with bad databases design but refactor is a must !.  
  
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment11</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment11</guid><pubDate>Mon, 22 Nov 2010 15:07:48 GMT</pubDate></item><item><title>Frans Bouma commented on NHibernate: Complex relationships</title><description>Paper about this subject by prof. T. Halpin: 
[http://www.orm.net/pdf/objectification.pdf](http://www.orm.net/pdf/objectification.pdf)</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment10</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment10</guid><pubDate>Sat, 20 Nov 2010 11:14:34 GMT</pubDate></item><item><title>Frans Bouma commented on NHibernate: Complex relationships</title><description>I'm with Victor, this isn't elegant at all. It's also wrong: PersonAddresses is an objectified relationship (in Object Role Modeling / NIAM terms), and this means it's an entity by itself. Just because it defines a m:n relationship between person and address doesn't make it an entity which doesn't exist, and the limitation that you can't persist new addresses shows that. 
  
  
I fail to see why PersonAddresses has to be wiped under the rug: its name is perhaps badly chosen, but it _is_ a valid entity, that you don't want to program with it, is really ignorance: because the entity exists in the domain, you have to deal with it, and which is the reason you have to deal with it too only in 'some other fashion'. 
  
  
The m:n relationship between person and addresses is readonly, over the objectified relationship. I do recall having a discussion with Fabio about this some time ago on nhusers. 
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment9</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment9</guid><pubDate>Sat, 20 Nov 2010 11:08:51 GMT</pubDate></item><item><title>Scooletz commented on NHibernate: Complex relationships</title><description>Good, old-fashioned blog entry. Interesting case.
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment8</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment8</guid><pubDate>Sat, 20 Nov 2010 08:51:50 GMT</pubDate></item><item><title>Fabio Maulo commented on NHibernate: Complex relationships</title><description>Can I refactorize that DB ? or it is untouchable ?
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment7</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment7</guid><pubDate>Fri, 19 Nov 2010 16:21:35 GMT</pubDate></item><item><title>Corey commented on NHibernate: Complex relationships</title><description>If you really want flexibility given the table structure above and still want to handle inserts.
  
  
Create a sql view that fits the exact mapping structure and let the view deal with the inserts appropriately.
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment6</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment6</guid><pubDate>Fri, 19 Nov 2010 14:23:46 GMT</pubDate></item><item><title>Max commented on NHibernate: Complex relationships</title><description>Oops, it seems my comment is stripped.
  
  
What about using idbag?
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment5</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment5</guid><pubDate>Fri, 19 Nov 2010 13:07:58 GMT</pubDate></item><item><title>Max commented on NHibernate: Complex relationships</title><description>What about using 
&lt;idbag?
&gt;</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment4</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment4</guid><pubDate>Fri, 19 Nov 2010 13:04:32 GMT</pubDate></item><item><title>JasonW commented on NHibernate: Complex relationships</title><description>The tabular model and the object structure in almost all cases will be quite different, with one modelling data and the other modelling behaviour. This is something that most ORMs don't handle as elegantly as the code above.
  
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment3</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment3</guid><pubDate>Fri, 19 Nov 2010 12:51:13 GMT</pubDate></item><item><title>Ayende Rahien commented on NHibernate: Complex relationships</title><description>Victor,
  
You need to map the PersonId column on the PeopleAddresses, and then you can threat this as a standard Many To One.
  
The scenario that was brought up was were there was another way of handling that, so I didn't bother with that
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment2</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment2</guid><pubDate>Fri, 19 Nov 2010 12:45:05 GMT</pubDate></item><item><title>Victor Kornov commented on NHibernate: Complex relationships</title><description>Pardon my ignorance, but how "you can’t add new addresses via the Person.Addresses collection" relates to the conclusion of "this is a pretty elegant solution"? All I can think of is having another set of classes\mappings just to be able to save the person's address. That's not elegant in my books.
</description><link>http://ayende.com/4695/nhibernate-complex-relationships#comment1</link><guid>http://ayende.com/4695/nhibernate-complex-relationships#comment1</guid><pubDate>Fri, 19 Nov 2010 12:25:30 GMT</pubDate></item></channel></rss>