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?)
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]<nhusers%[email protected]> > > <mailto: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]> > > <mailto: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]<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.
