The main issue here as Frans mentioned earlier, is how to map classes implementing the Actor - Role pattern. This could come in various forms. This seems to be the situation being described. Other incarnations could be:
Actor Role ---------------------- Person Employee Person Customer Company Customer Company Supplier Person Student These relationships suggest a one-to-one between the Role and the Actor, Employee and person, Customer and person, Customer and Company, Supplier and company etc. The complication stems from how you view the other side of the relationship i.e. from the Actor to the Role: Person to Employee and Person to Customer, especially if you're trying to make the relationships bidirectional. If you view the relationship from Actor to Role as one-to-one and try to make the Person to Employee, Company to Customer etc relationships one-to-one as well as bidirectional, you run into all kinds of problems. I had posted something on the nhibernate forum about this before, you can also read it. https://forum.hibernate.org/viewtopic.php?f=25&t=1000516 I was at the time also documenting my attempts at solving the problem through varios combinations of the mapping options which I was going to post as well but don't seem to find it again, [I hope i'm not imagining things]. The compromise solution I adopted at the end of my explorations was to view the Actor to Role relationship as one-to-many and not one-to-one and map it as such. This can actually be correct in some cases where you want to maintain multiple customer relationships for a company with different terms applied, or a person with more than one employee record. But it may not seem right for your situation. So Actor class like a company you would have the following code to morph the one-to-many back to a one-to-one. Company { Ilist<Customer> _customers; public Customer Customer { get { return _customers[0]; } set { _customers.Add(value); } } } I would have some guard clauses to prevent assigning more than one customer to a company. And i was also using field access so I did not have to expose a Customers property. If I can still find the stuff I had written I will post it too. hope this helps. Jide On Aug 11, 6:11 pm, Diego Mijelshon <[email protected]> wrote: > You seem to have a problem with the definition of your entites. > Can you do a simple diagram of how you see your domain? > Maybe it's just a miscommunication. What I can tell you is, this is NOT a > complex model at all, NOR will you have to jump through any hoops... as long > as you get the model right. > > The name change was because you said "a contact might not be a client". > Fine, so the superclass is not "Client". But what makes a "Client" different > from a Contact/Company? > > Diego > > > > On Wed, Aug 11, 2010 at 13:53, Blaise <[email protected]> wrote: > > > How about changing the name "Client" to "BusinessPartner"? > > > Then, the "Client" property of your Invoice class is a BusinessPartner. > > > Not following you. How does changing the name of an entity solve > > anything ? > > > Frans' conclusion is pretty much the one I was afraid of earing > > - either try to jumps through unnatural hoops, which I don't like > > - or just duplicate the data (John Doe the friend and John Dow the > > business partner), which I don't like either. > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en.- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
