思考ValueObject应该更多从内存的角度思考,而非DB持久化的角度。
例如:
public class A { public int Id { get; set; } public Address A_Address { get; set; } } public class B { public int Id { get; set; } public Address B_Address { get; set; } } public class Address { public Address(string city, string street) { this.City = city; this.Street = street; } public string City { get; private set; } public string Street { get; private set; } }
在数据库中的结构是:
可见表A和表B都有自己的Address_City和Address_Street,如果类A和类B有一个相同的地址,那么将在数据库中有两条相同的记录,这似乎不符合Value Object的共享特性。如果这么思考,我们可能会把以上的例子修改,修改后的类如下:
public class A { public int Id { get; set; } public int Address_Id { get; set; } } public class B { public int Id { get; set; } public int Address_Id { get; set; } } public class Address { public int Id { get; set; } public string City { get; set; } public string Street { get; set; } }
这样一来,虽然在数据中是可以共享数据了,但Address却变成了一个Entity,而非ValueObject了。
在思考ValueOjbect的共享特性时,应该多从内存角度出发,而非数据库的存储角度。也就是说我们在考虑DDD的时候,应该抛开数据库思考,多思考一下对象在内存中是如何共享的,而持久化的操作交给Repository来做就行了,无论在数据库中是如何持久化的。
ValueObject平时使用时,复制的情况一般会多于共享的情况。因为一旦被多个对象共享那这个ValueObject将不可被销毁,除非没有被任何其他对象引用。
为了能够尽量利用共享带来的好处,同时避免它的缺陷,只在以下情况中使用共享:
1. 当数据库中的存储空间和对象数量有严格限定时。
2. 当通信开销不高时(例如在一个中心服务器上)。
3. 当共享对象具有严格的不变性时。
另外:DDD中Value Object的共享性更多使用在多线程中,在分布式业务中多使用复制