> Thanks Frans for the explanation but if you could bear with me a bit more:
> I understand the idea of using a component that has the actual columns in
> the parent table instead of a separate table. But as far as I know this
> works if the component is a single instance and not a collection:
> Person.SingleContactInfo
> Not Person.ListOfContactInfo
> because a list of contactInfo would not be of a predetermined size, so how
> would the columns be on the database side (how many columns to represent
the
> contactInfo?)
that's indeed a problem with using components in this case: a
flexible list of contact infos, which can be extended till whatever size is
indeed requiring that you model it outside the entity. I refered to
'phonenumber' as a metaphore in my previous email as you often see this
happening with phonenumber as well: "we need different types of
phonenumbers: mobile, landline, work, home, second, third. etc..", which
could indeed be done by creating an entity out of it (so keep ContactInfo as
a separate entity), but it's also a sign you might want to take a step back
and think about if you need the list of contact info's, as it comes with a
price: you need extra logic, as I described.
Say you want to stick with the list thing, and really want it that
way, you can keep the ContactInfo table, and solve it in two ways:
1) Keep it but it's only for Employee. Add an FK to Employee in the
ContactInfo table and rename the table to EmployeeContactInfo. This is
straight forward.
2) Create a ContactGroup table, which contains 1 field: ID* and in the
tables which have to have a list of contacts, add an FK field to
ContactGroup. In ContactInfo, add an FK to ContactGroup. So EMployee '5' has
as ContactGroupId (the fk to ContactGroup) the value '3', and in ContactInfo
there are 1 or more rows with the FK field ContactGroupId set to 3. To
obtain the contacts for Employee, you thus join with Contactgroup and
ContactInfo.
FB
>
> Thanks
>
>
> On Sun, Aug 15, 2010 at 1:44 PM, Frans Bouma <[email protected]> wrote:
>
>
> > The main problem is that ContactInfo is not used by only the
> Employee
> > Entity, that is why I am not sure how to design it on the database
> side.
>
>
> You mix type with instance. If you define a ContactInfo
> component
> (Valuetype in DDD), it's a type. You can re-use that in multiple
> entities.
> It just doesn't have its own table, as it's not a separate entity
> (you can't
> save it separately and fetch it separately, as it doesn't make
sense,
> it
> only makes sense in the context of its containing entity)
>
>
> > Also, specifiying JUST 3 Contact Infos for the Employee does not
> work
> since
> > the user must be able to add and remove from the contact info as a
> list.
> > Same goes for Address table, it is used by more than one entity
and
> probably
> > by the same entity more than once.
>
>
> Instance or type re-use? I was talking about instance re-use.
> In
> almost all applications which request an 'address' to be filled in,
> you
> can't select one from a list, you just fill in the fields, like with
> name,
> day of birth etc. So the fields making up the 'address' are simply
> part of
> the entity they belong to, you won't share an address instance (i.e.
> the
> data!) with another entity by letting that OTHER entity reference
the
> same
> row, but you will do that with a real entity, like Customer.
>
> Address, and also contact info, phone numbers (same thing),
> are 'on
> the edge' of being seen as entity or valuetype, as you can add an
> 'id' and
> it looks like an entity. But you've to think about how it behaves in
> the
> domain model: what is its purpose: if its purpose is to group fields
> inside
> an entity, you shouldn't create it as an entity, but as a component
> (valuetype).
>
> Your UI reference that the user should add/remove it from a
> list is
> typical for the point of view where address, contact info,
> phonenumber etc.
> are seen as real entities, but a question was asked how to model it,
> and I
> think it's wiser to look into why you'd really want to define it as
> an
> entity. For example, your list idea in the UI, requires extra logic,
> like do
> I allow 10 contact info's all of the same type for an employee? Does
> it have
> to have contact info of at least 3 different types?
>
> FB
>
>
>
> >
> >
> >
> >
> > On Sun, Aug 15, 2010 at 12:33 PM, Frans Bouma <[email protected]> wrote:
> >
> >
> > > I have a ContactInfo Table :
> > > ContactInfo(
> > > ID int IDENTITY(1,1) NOT NULL, --PK
> > > ContactValue varchar(100) NOT NULL,
> > > ContactType smallint] NOT NULL
> > > )
> > > In my model multiple entities/tables would need to have a
> list of
> > > ContactInfo entries.
> > > Example:
> > >
> > > Employee has 3 contact infos: 1 email and 2 phone numbers.
> I would
> > then
> > have
> > > a ContactInfo with ContactType = 2(email), and 2
> ContactInfo with
> > Type =
> > > 1(phone).
> >
> >
> > ContactInfo isn't an entity. An entity is a group of
> > attributes
> > (fields) with its own identity. Your contact info isn't
that,
> it's 1
> > value.
> >
> > So I'd model it as a Component, and define 3 contact
> infos in
> > Employee. This is less flexible (you can't add more without
> modifying
> > employee), however it's IMHO better, because you're not
going
> to re-
> > use
> > contactinfo. It's the same as address. A lot of people model
> that as
> > a
> > separate entity, which is in most cases not really
> beneficial, as
> you
> > don't
> > re-use entity instances (rows in the table)
> >
> >
> > FB
> >
> >
> > > Now the question is how to link this Entity to the
> different
> users?
> > It
> > looks
> > > like inheritance with only a difference in foreign keys.
> Does
> > adding an FK
> > > to every user Table make sense / good design?
> > >
> > > Also, how do we represent such a thing in the domain
model?
> Do we
> > create
> > > duplicate classes for every use? EmployeeContactInfo,
> > ClientContactInfo,
> > > etc... How do we map those?
> > >
> > > I know those are a lot of questions but I think the idea
is
> clear
> > enough,
> > > thanks for the help in advance.
> > >
> > > --
> > > 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]
> <mailto:nhusers%[email protected]>
>
> > <mailto:nhusers%[email protected]
> <mailto: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]
> <mailto:nhusers%[email protected]>
>
> > <mailto:nhusers%[email protected]
> <mailto: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]
> <mailto: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]
> <mailto: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.
--
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.
