如何改进网站,上市公司网站维护,做内贸的电子商务网站典型有,上海公关公司排行榜0.引言 在现有的系统开发中#xff0c;大部分的系统应该都会用到ORM#xff0c;无论用的是EF还是NHibernate。作为对象和持久化数据的桥梁#xff0c;ORM确实非常方便#xff0c;以至于在DDD的时候#xff0c;我们很自然的将 ORM中的Model(实体)表达成DDD中的 DomainModel…0.引言 在现有的系统开发中大部分的系统应该都会用到ORM无论用的是EF还是NHibernate。作为对象和持久化数据的桥梁ORM确实非常方便以至于在DDD的时候我们很自然的将 ORM中的Model(实体)表达成DDD中的 DomainModel领域对象。 但这真的合理吗我们先引入两个例子来探讨这个问题。 1.例子1订单聚合 下述聚合引自汤神的博客: 我们看以上的聚合设计非常经典。Order对象作为聚合根OrderItem建模成实体只要在当前的订单聚合中不重复即可。 但在真正的数据存储的时候我们的OrderItem对象肯定不能是这样子的。 假如我们有两个订单A和B订单A包含了商品1和商品2订单2包含商品2和商品3。 那么很明显我们如果以OrderItem这个实体去存储必然会造成主键重复。在实际存储的时候我们肯定也会为OrderItem增加其他的字段用来存储他自己的主键信息。 比如我们给他建立一个独立的ID public class OrderItem{/// summary/// 订单项ID/// /summarypublic string Id { get; set; }public string ProductId { get; set; }public string ProductName { get; set; }public float Price { get; set; }public int Count { get; set; }} 或则采用联合主键 public class OrderItem{/// summary/// 订单ID/// /summarypublic string OrderId { get; set; }public string ProductId { get; set; }public string ProductName { get; set; }public float Price { get; set; }public int Count { get; set; }} 2.例子2旅馆聚合与房间聚合 在旅馆信息系统管理里面对旅馆的操作会有独立的模块参考聚合的设计原则 如果领域内的一个对象我们会在后台有一个独立的模块去管理它那它基本上也是聚合根了所以我们建立旅馆聚合代码如下 public class Hotel{/// summary/// 聚合跟id/// /summarypublic string Id { get; set; }/// summary/// 值对象/// /summarypublic string Name { get; set; }/// summary/// 房间列表 此处简单标示 /// /summarypublic IListstring Rooms { get; set; }//其他信息略//...} 对于旅馆房间的也一样我们会有单独的模块去管理而且房间有单独的状态标示房间是否有人入住是否空房等等 房间聚合如下 public class Room{/// summary/// 房间id/// /summarypublic string Id { get; set; }public string Name { get; set; }public string RoomType { get; set; }// 空 已预订已入住脏房间等状态public RoomStatus Status { get; set; }/// summary/// 旅馆聚合根ID/// /summarypublic string HotelId { get; set; }} 如果是在ORM中上述很可能表达成如下实体 public class Hotel{public string Id { get; set; }public string Name { get; set; }/// summary/// 房间列表 /// /summarypublic virtual IListRoom Rooms { get; set; }//其他信息略//...} 和房间实体 public class Room{/// summary/// 房间id/// /summarypublic string Id { get; set; }public string Name { get; set; }public string RoomType { get; set; }// 空 已预订已入住脏房间等状态public RoomStatus Status { get; set; }/// summary/// 旅馆/// /summarypublic virtual Hotel Hotel { get; set; }} 很明显的可以看出上述模型不是DDD中的领域对象模型。 3.结论ORM中的Model不应该与DDD中的DomainModel等价 更多的我们在设计数据库表的时候为了查询性能考虑会冗余一些信息等等。 通过以上的分析我们可以得出结论ORM中的Model不应该与DDD中的DomainModel等价。 我藉著本文来抛砖引玉。 国外的大牛写的Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx 转载于:https://www.cnblogs.com/zhengqzheng/p/5883612.html
