> 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]> .
> > 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.
