开发者

Collection of components - does it make sense?

开发者 https://www.devze.com 2023-04-05 01:07 出处:网络
I\'m using NHibernate for some time and pretty often, when I need to map parent-child collection in which the children are fully dependent from its parent, I map these associations as collection of co

I'm using NHibernate for some time and pretty often, when I need to map parent-child collection in which the children are fully dependent from its parent, I map these associations as collection of components.

I always thought that when children have no own lifecycle, they should be mapped as components, to be logically correct. But I'm trying to find arguments closer to the implementation level and I can't see any gain from component collections that I can't easily have 开发者_如何学编程using standard one-to-many mapping. Moreover, I can see some serious cons:

  • components in collections like this are always deleted and reinserted on each update, what may be a big performance hit when the collection contains hundreds of elements
  • schema generated by default use table with no primary key to hold the components - it's against database good practices

What are the real-life scenarios that make collection of components mapping really useful?


When you design an application, your main concern should be about business logic, that is why you need to design your domain layer using entities and value objects.

When you design applications in this way you implement an object either as entities with identity or value objects which are immutable, it is not logical to put an identity to a color object or a user address object (unless it is a shipping application or so).

You should design your domain model to be as Persistence Independent as possible to abstract out the technical data store and concentrate on business logic which is the main objective of your application.

When you reach the implementation of mapping layer using orm like NHibernate, you map value objects as components because they does not have identity, and it is not logical to corrupt the domain and put identity just for persistence. think also about the immutability nature of these components, when you change a color or an address you are actually not modifying it you are replacing it given that value objects regularly small, adding an explicit id will not add any benefit even in terms of database as you will not need to index them, seek them by id or even query them separately so adding id will just complicate the storage.

if you found your component collection is rather large or complex then you may be mis-using the value object and you may need to re-design it or convert it into entity with identity.

check out this and this for more details

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号