Dead-on summary of my situation

On Aug 11, 10:01 pm, JideO <[email protected]> wrote:
> 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.

Reply via email to