<any> http://nhforge.org/doc/nh/en/index.html#mapping-types-anymapping
On Sun, Aug 15, 2010 at 4:17 PM, Muhammad Shehabeddeen < [email protected]> wrote: > I went with this: > > Table > > ContactInfo > id > ContactValue > ContactType > Employee_ID_FK > Customer_ID_FK > ANY_CONTACT_USER_FK > etc > . > . > . > > > Class > public class Contact > { > public virtual string ContactValue { get; set; } > public virtual short ContactType { get; set; } > } > > Here is dummy table that uses contact info: > DummyContactUser( > ID > Name > ) > and the class: > > public class DummyContactUser > { > public int ID { get; private set; } > public string Name { get; set; } > public ISet<Contact> ContactInfo { get; set; } > public DummyContactUser() > { > ContactInfo = new HashedSet<Contact>(); > } > } > > and a mapping like this: > > public class DummyContactUserMap : ClassMap<DummyContactUser> > { > public DummyContactUserMap() > { > Not.LazyLoad(); > Id(x => x.ID); > Map(x => x.Name); > > HasMany(x => x.ContactInfo) > .Component(x => > { > > x.Map(y => y.ContactValue); > x.Map(y => y.ContactType); > }) > .Not.LazyLoad() > *.Table("ContactInfo")* > *.KeyColumn("ANY_CONTACT_USER_FK");* > } > } > > So as you can see I implemented it as a set of Components where I am using > the foreign key as the key column and I would do that kind of mapping for > every class that needs ContactInfo by changing the FK I use for each. > > Does this make sense? Any pitfalls I might have missed? > Thanks. > > > On Sun, Aug 15, 2010 at 3:24 PM, JideO <[email protected]> wrote: > >> You could use >> >> ContactInfo >> Id >> ContactValue >> ContactType >> ... >> Employee >> EmpId >> StaffNo >> ... >> EmployeeContactInfo >> EmpId >> ContactInfoId >> ... >> Person >> PersonId >> FirstName >> ... >> PersonContactInfo >> PersonId >> ContactInfoId >> ... >> >> etc etc. You'd have one EntityContactInfo table for each Entity that >> needs to use the ContactInfo. The relationship between >> EntityContactInfo and ContactInfo can simply be unidirectional but i'm >> sure it can be done bidirectionally with some inheritance. >> >> A warning, as FB has noted earlier, this comes with the responsibility >> of managing the additional complexity that comes with what this >> multiple unlimited address thing. If you have no other choice...but >> sometimes reexamining what you're trying to achieve may help you >> simplify it a little. >> >> Jide >> >> >> On Aug 15, 12:45 pm, "Frans Bouma" <[email protected]> wrote: >> > > 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]<nhusers%[email protected]> >> > > <mailto:nhusers%[email protected]<nhusers%[email protected]> >> > >> > >> > > > >> > > <mailto:nhusers%[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]> >> > >> > >> > > > >> > > <mailto:nhusers%[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]> >> > > <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.- Hide quoted text - >> > >> > - Show quoted text - >> >> -- >> 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. > -- Fabio Maulo -- 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.
