实体框架之领域驱动实践（一）：从DataTable到EntityObject

核心提示： EF目前不支持聚合概念,所有的实体都被一股脑地塞进ObjectContext对象的EntitySet属性当中,不过这没关系,接下来的文章我会介绍如何在EF中引入聚合的概念值对象支持.了解领域驱动设计的朋友都知道,领域模型对象分为实体、值对象和服务.以前的LINQ to SQL不支持值对象,很郁闷

EF目前不支持聚合概念,所有的实体都被一股脑地塞进ObjectContext对象的EntitySet属性当中,不过这没关系,接下来的文章我会介绍如何在EF中引入聚合的概念

值对象支持.了解领域驱动设计的朋友都知道,领域模型对象分为实体、值对象和服务.以前的LINQ to SQL不支持值对象,很郁闷,现在好了,EF支持值对象,其表现为ComplexType类型.在这里我想提两点,首先,EF还不支持枚举类型,不要小看枚举类型,与整型类型相比,它能够更好地表达领域语义,比如销售订单的状态可以有 Created,Picked,Packed,Shipped,Delivered,Invoiced,Returned和Cancelled,如果用 0,1,2,3,4,5,6,7来表示,你就会看不懂了,因为这些整数都不是“自描述”的,你需要去读额外的文档来了解它们的意思.其次就是我不太喜欢将 ComplexType定义为引用类型,我觉得用值类型就会更加轻量.当然,我不反对使用引用类型,毕竟EF也是出于框架设计的需要

实体不仅有状态,还应该有行为.这是很自然的事情,我们应该使用“富领域模型”,而不仅仅是搞一些POCO加一些 getter/setter方法.因为对象本身就应该有行为,这才能够以自然的方式描述现实领域.很可惜,EF的Entity Data Model Designer只支持对象状态(属性)的图形化定义,而不支持行为定义,这也给EF带来了一个硬伤:没法定义行为的重载和重写,而这些却恰恰是业务逻辑的重要组成部分.我更希望在下一代EF中,能够看到的是“Entity Model Designer”,而不是“Entity Data Model Designer”.当然,我们也可以通过使用C#中部分类(partial class)的特性,向实体注入行为,这并不影响实体对领域概念的描述性.

最糟糕的就算是,EF居然支持从数据库的存储过程来生成实体对象的方法.这从根本上把技术问题和领域问题混为一谈,我认为这个功能也可以去掉,因为存储过程面向的是数据,而实体方法面向的是领域.有关存储过程的问题,我在后面的文章中也会提到

从上面的描述,我们对EF的功能有了个大概的了解,接下来的系列文章,我会和大家一起,一步步地探讨,如何在EF上应用领域驱动设计的思想,进而完成我们的案例程序.本系列文章均为我个人原创,或许在某些问题上你会有不同意见,不要紧,你可以直接签写留言,或者发邮件给我,期待与你的探讨,期待与你在软件架构设计的道路上共同进步.