> 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
if you want to use referential integrity, you can't use <any>.
> 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.
Ok, so in short: you have an entity E which can have multiple roles:
contact, employee, contractor etc. This is important, because it solves the
situation where a contact is an employee AND a client.
> 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.
It's very complex actually. What makes you think it's simple?
because you mentioned just 3 entities in your earlier email? :) that doesn’t
make it simpler, you were just telling half the story.
You try to simplify it by thinking 'a contact is what I work with
and they can be A, B and C but in another situation, they can only be D',
and that's precisely why this goes wrong: if an Employee is an Employee,
it's not a company. It's either solvable with a very big inheritance model
(not recommended) or loosely coupled subgraphs. With loosely coupled I mean:
say John Doe is working for Foo Inc. John is a Contact, and Foo Inc is a
company. Now, John has a business on the side and you hire him as well as a
Contractor. While John is phyiscally the same person, is it the same entity
_instance_ you want to file as Contractor AND as Contact for Foo Inc. ? If
no, it's solved: simply fill in the data for the Contractor entity and
you're done. If yes, you need to be able to assign the contractor role to a
contact (or a contact role to a contractor), this either requires role
management (which causes extra joins with a role table, complex filtering)
or you use a non-coupled set of tables with <any>, however referential
integrity is then out the window.
I'd keep things simple and go for the option that you see Contractor
John as a different entity than Contact John, so you simply have two
tables/entities for that and just because they are IRL physically the same
person, it doesn't mean they have to be the same entity (as in theory, they
do represent different things)
FB
>
> 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%2bunsubscr...@googl
> > > > > nhusers+egroups.com >
> > > .
> > > > > 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%2bunsubscr...@googlegro
> > > nhusers+ups.com >
> > > .
> > > 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.
--
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.
