Collections of components - an alternative

In a project I work in we have a lot of places in our data model where an entity has some properties collections used just for displaying it to the customer, like list of company locations or source URLs for the document. We are not filtering/querying our data by these properties at all and we're pretty sure we wouldn't do that in the nearest projects lifetime.

It may seem right to map these collections in NHibernate as collections of components. Component in NHibernate is an object without its own identity, always being a part of its parent entity - so called value type. The classical example is User entity and Address component. There can be no Address that doesn't belong to any User, and deleting the User will delete the Address, too. Component mapping is designed for representing single database row as multiple objects (User and its corresponding Address are mapped from single row in Users table).

Our URLs or company locations sounds similiar in terms of lifetime and ownership, but totally different in terms of relationship - these are one-to-many relationships instead of simple one-to-one in User-Address example. Because of that, different approach is needed to store the data. The road we took at the beginning was the most obvious one for someone who learned about database normalization rules - we've created separate tables for each of the collections - i.e. CompanyLocations table with CompanyId foreign key and string-typed column for the location. When mapping these tables in NHibernate, we still didn't want to give rows from these tables its own identity - logically they were still owned by our main entities, i.e. Company. So we mapped it as collections of components:
   
mapping.HasMany(x => x.Locations).AsBag()
    .Component(m => m.Map(x => x.Location));

Read more: NOtherDev
QR:

Posted via email from Jasper-Net