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

核心提示： 先不说EF,首先我们简要地分析一下,作为一种框架,要支持领域驱动的思想,需要满足哪些硬性需求,之后再仔细想想,.NET EF是否真的能够很好地应用在领域驱动上.首先需要能够正确对待“领域模型”的概念.领域模型与数据模型不同,它表述的是领域中各个类及其之间的关系.类关系是多

先不说EF,首先我们简要地分析一下,作为一种框架,要支持领域驱动的思想,需要满足哪些硬性需求,之后再仔细想想,.NET EF是否真的能够很好地应用在领域驱动上.

首先需要能够正确对待“领域模型”的概念.领域模型与数据模型不同,它表述的是领域中各个类及其之间的关系.类关系是多样的,比如组合、聚合、继承、实现、约束等,而数据模型不是一对多,就是多对多.从领域驱动设计的角度看,数据库只不过是存储实体的一个外部机制,是属于技术层面的东西.数据模型主要用于描述领域模型对象的持久化方式,应该是先有领域模型,才有数据模型,领域模型需要通过某种映射而产生相应的数据模型.因此,框架必须支持从领域模型到数据模型的映射.

EF不仅支持从领域模型生成数据库的DDL,而且支持从数据库结构来生成“领域模型”.我倒是觉得后者可以去掉,因为从数据库得到的已经不是领域模型了.你会问为什么,我可以告诉你,单纯的数据是没办法描述领域概念的.比如:你的数据库里有一个表叫做 “Customer”,在通过数据库结构生成“领域模型”的时候,Visual Studio当然会帮你生成一个“领域对象”叫做Customer,但如果我把这数据表的名字改为“abc”,虽然里面还是存的客户信息,但EF并不知道这一点,也是照样生成一个“abc”的类,而这样的东西能算是领域对象吗?因此,数据依赖于实体,是实体的状态,离开实体的数据毫无意义

对“聚合”概念的支持.聚合是一系列表述同一概念的相互关联的实体的集合,比如销售订单、销售订单行以及商品,这三个实体可以整合成一个聚合,销售订单则是聚合的根.关于聚合的问题将在后续文章中讨论.为什么引入聚合?这是领域驱动设计处理大型软件系统的一种独到的方式.软件系统的实体对象可能非常多,之间的关系也可能错综复杂,那么,当我们需要从外部持久化机制“唤醒”(或者说读取)某个实体对象的时候,是不是需要将它以及它所关联的所有对象都一并读入内存呢?当然不是,因为我们只需要关注整个问题的某个方面.比如在读取客户数据的时候,我们或许会将这个客户的所有订单显示出来,但不会将每个订单的订单行也全部读出来,因为现在我们还没有决定是否真的需要查看所有的订单行.