You still have conceptual OOP problems.
How about changing the name "Client" to "BusinessPartner"?
Then, the "Client" property of your Invoice class is a BusinessPartner.
There.
It's not complicated at all, but you MUST think in objects.
If you keep trying to take a non-object-oriented datamodel and somehow
transform it into objects, you'll end up with a mess.
Diego
On Wed, Aug 11, 2010 at 11:52, Blaise <[email protected]> wrote:
> I'll look into details at the <any> attribute, but it looks
> incompatible with enforcing a FK constraint at the DB level, which is
> a good sanity check
>
> As for the role of a Company or a Contact, it's just that we need to
> interact with these without them being clients.
> Contacts and Companies are there for address book purpose mainly,
> and a Contact often works for a Company that is not necessarily a
> client.
> But some Contacts may be employees, or contractors etc... And
> Companies can represent suppliers, or other partners for instance.
>
> What surprises me is the apparent simplicity of my domain model. If I
> where to do a DAL manually, it'd be fairly simple and queries would be
> natural, yet, it looks like I'm out of the usual easily-supported
> scenario.
>
> Blaise
>
>
> On Aug 11, 4:31 pm, Diego Mijelshon <[email protected]> wrote:
> > You CAN use heterogeneous relationships (see <any>). But I still believe
> you
> > are not modeling right.
> > What is the role of a Company or Contact in your application, besides
> being
> > a Client?
> > Put another way, in which relationships does it appear, that are
> completely
> > unrelated to selling stuff to them?
> >
> > Now, if the *final user* of the application only considers these entities
> > "Clients" after making a sell, that's something to take care of in the UI
> > (or service layer, whatever).
> >
> > Diego
> >
> >
> >
> > On Wed, Aug 11, 2010 at 10:50, Blaise <[email protected]> wrote:
> > > I can't seem to explain clearly. Let me try again :)
> >
> > > a Contact is a person like you and me. it has a firstname, a lastname,
> > > a date of birth etc...
> > > a Company is a business, with a name, employees etc...
> >
> > > Then we sell stuff to Clients. So a client has number, receives
> > > quotes, bills etc
> > > But a client (in the business sense) can be a another business (a
> > > Company) or an individual (a Contact).
> > > Again, not all Companies are Clients. Same for Contacts.
> >
> > > So Contact, Company and Clients are three completely different
> > > entities that should not share an inheritance hierarchy.
> > > But a Client must reference either a Contact or a Company
> >
> > > Is that clearer ?
> >
> > > The natural way of mapping that to a schema for me was to have to
> > > foreign keys in the table Client, one for Contact and one for Company,
> > > each with a unique constraint on it. But that doesn't play well with
> > > nHibernate.
> >
> > > Thanks
> >
> > > Blaise
> >
> > > On Aug 11, 3:01 pm, "Frans Bouma" <[email protected]> wrote:
> > > > > So, I'm back with my initial problem, except I'm free to design the
> db
> > > > > schema as I see fit.
> > > > > But even with _no_ constraint watsoever, I can't seem to find a
> correct
> > > > way
> > > > > to map my classes to my DB.
> >
> > > > > The scenario is simple, and probably very common too (still the
> same
> > > > > scenario as my initial post) :
> > > > > We've got Clients. Clients can be businesses or customers.
> > > > > So in terms of classes, we have Client, Contact and Company.
> > > > > A Contact has a property Client (may be null because not all
> Contacts
> > > are
> > > > > clients). Same for Company.
> > > > > And a Client has two properties, Contact and Company, but only one
> of
> > > them
> > > > > is non null.
> >
> > > > I find it hard to follow: a client can be a business or a
> > > customer,
> > > > yet you say you have client, contact and company. Where's customer?
> >
> > > > Also you shouldn't think in properties, but in relationships.
> FK
> > > > side depends on PK side, and only 1 PK side. What you want is to
> switch
> > > > between PK sides for a given FK side, that's nonsense, since the FK
> > > side's
> > > > fields (for mapping, the FK fields in the table you map in the
> mapping
> > > > files) are derived from the PK fields they refer to. That's what it
> > > means:
> > > > Customer 1:n Order -> Order gets the PK field of Customer as FK
> field.
> > > You
> > > > seem to want to switch between PK sides, which is incorrect.
> >
> > > > However, I fail to see why you want this. You don't think in
> > > > entities and their relationships but in code and how to cram that
> into
> > > some
> > > > tables. That's the wrong way to look at things: try first to
> determine
> > > which
> > > > entities you have (I assume: Client, Company (subtype of Client) and
> > > > Customer (subtype of Client), and Contact) and how they relate to
> > > eachother,
> > > > THEN try to create a model from that in the DB, preferably by using
> T.A.
> > > > Halpin/Nijssen's approved system to project an abstract entity model
> with
> > > > inheritance onto a relational model, e.g. what's been used in
> ORM/NIAM.
> > > This
> > > > is pretty straight forward, you have to make a decision whether you
> want
> > > to
> > > > create 1 target (table) for an inheritance hierarchy or 1 table for
> each
> > > > entity in the inheritance hierarchy but that's about it. The main
> problem
> > > is
> > > > which entities there are, and how they relate to eachother, as you
> don't
> > > > seem to have that figured out yet.
> >
> > > > FB
> >
> > > > > We could model that with an abstract class Client, and two contrete
> > > > classes,
> > > > > BusinessClient that has a non null Company property and a
> > > CustomerClient
> > > > > that has a non null Contact property.
> >
> > > > > The natural (for me) db schema doesn't work (cf earlier post).
> > > > > So I'm trying to have my one-to-one mappings on the primary key,
> that
> > > is
> > > > if
> > > > > a Client is b2c, then the Client PK is the PK of the Contact, and
> if a
> > > > > Client is b2b, the Client PK is the PK of the Customer.
> >
> > > > > But that doesn't really work either because nHibernate Id generator
> > > > > "foreign" only accepts a single entity has a foreign key source.
> >
> > > > > And Creating a class hierarchy doesn't work eigher because the
> > > generator
> > > > > must apparently be set at the root class.
> >
> > > > > So I welcome any advice, because I'm somewhat stumped: my domain
> model
> > > is
> > > > > simple, yet I can't seem to find a good and simple way to map it to
> a
> > > > > storage model.
> >
> > > > > Thanks
> >
> > > > > Blaise
> >
> > > > > On Jul 26, 2:49 pm, Fabio Maulo <[email protected]> wrote:
> > > > > > aaahhh you never said you are using a Eliot Ness DB.
> >
> > > > > > I'll check what happen with your Eliot Ness.
> >
> > > > > --
> > > > > 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]>
> <nhusers%[email protected]<nhusers%[email protected]>>
> > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/nhusers?hl=en.
> >
> > > --
> > > 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]>
> <nhusers%[email protected]<nhusers%[email protected]>>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nhusers?hl=en.
>
> --
> 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.
>
>
--
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.
