EntityFramework领域驱动设计实战指南：从疑问到解决方案

36 浏览量更新于2024-07-15 收藏 678KB PDF 举报

本文档围绕Entity Framework进行深入探讨，特别是在领域驱动设计（DDD）实践中的应用。作者根据网友的讨论和自己的实践经验，逐步展开了一系列详细的教学内容，旨在帮助读者理解和掌握Entity Framework在DDD中的运用。首先，文章从"EntityFramework之领域驱动设计实践-前言"开始，强调了Entity Framework相较于LINQ to SQL的改进，即它将系统的关注点从数据库驱动转向了模型和领域的驱动，更适合DDD的理念。在.NET Framework 4.0版本中，Entity Framework已经成为内置组件，对于.NET 4.0用户来说，无需额外安装。接着，文章分为十个部分，详细讲解了从基础概念到实际操作的各个方面： 1. "从DataTable到EntityObject"部分介绍了如何从传统的数据表模型转换到Entity Framework中的实体对象模型。 2. "分层架构"章节涉及了应用程序架构的设计，如何通过三层（或更多层）结构组织代码，以保持模型的独立性。 3. "案例：一个简易的销售系统"提供了实例，展示了如何在实际项目中使用Entity Framework实现领域驱动设计。 4. "存储过程-领域驱动的反模式"讨论了如何避免在领域驱动设计中滥用存储过程，保持设计的清晰度和可维护性。 5. "聚合"讲解了领域模型中的聚合原则，以及如何在Entity Framework中体现。 6. "模型对象的生命周期-工厂"和"仓储"探讨了对象创建和管理的最佳实践，包括使用工厂模式和仓储模式。 7. "仓储的实现（基本篇）"和"深入篇"分别介绍了仓储的具体实现方法和技术细节。 8. "规约（Specification）模式"涉及领域驱动设计中的业务规则验证，如何通过规约来确保数据的一致性和有效性。 9. "服务（Services）"部分介绍了如何利用服务来封装业务逻辑，保持模型的纯粹性。 10. "CQRS体系结构模式"讲解了命令查询责任分离（CQRS）架构在Entity Framework中的应用，提高系统的可扩展性和性能。最后，文档还包含了"扩展阅读"，链接到其他相关主题，如DDD的更高级概念和架构模式，帮助读者进一步深化理解。整体而言，本文档为读者提供了一个实用且深入的Entity Framework在领域驱动设计中的实践指南，通过实例和理论相结合的方式，使学习者能够更好地在实际项目中应用DDD原则。

有朋友会问，为什么我们要另外使用部分类，而不是直接在模型文件 edmx的源代码上直接修改？因为这个源代码文件是框架

动态生成的，如果在上面修改，等下次模型被更新的时候，你所做的更改便会丢失。

对于实体的行为，EF支持从数据库存储过程生成实体对象行为的过程。对此，我持批判态度：EF把数据模型与实体模型混为

一谈了，这种做法只能让软件人员感到更加困惑。我在下一篇文章将重点表述我对这个问题的看法。我也相信微软在下一代实

体框架中能够处理好这个问题。

再次，EF对实体对象关系的支持主要有关联和继承。根据Multiplicity的设置，关联又可以支持到组合关联与聚合关联。我觉得

EF中对继承关系的支持是一个亮点。继承表述了“什么是一种什么”的观点，比如在我们的案例中，“销售订单”和“退货单”都是

一种“单据”。如果从传统的数据库驱动的设计方案，我们很自然地会使用“Orders”数据表中的整型字段“OrderType”来保存当前

单据的类型（比如0表示销售订单，1表示退货单），那么，在获取系统中所有销售订单的时候，我们会使用下面的代码：

List<Order> GetSalesOrders(IDbConnection connection)

{

IDbCommand command = new SqlCommand("SELECT * FROM [Orders] WHERE [OrderType]=0",

(SqlConnection)connection);

List<Order> orders = new List<Order>();

using (IDataReader dr = command.ExecuteReader())

{

while (dr.Read())

{

Order order = new Order();

order.Id = Convert.ToInt32(dr["Id"]);

// ...

orders.Add(order);

}

dr.Close();

}

return orders;

}

从技术角度讲，上面的代码没什么问题，运行的也很好，能够获得系统中所有销售订单的列表。但是， [OrderType]=0这种写

法并不包含任何领域语义，如果让另一个开发人员来跟进这段代码，他不得不先去查阅其它项目文档，以了解这个

[OrderType]=0的具体涵义。在引入了继承关系的EF中，我们只需要下面的Linq to Entities，即可既方便、又明了地获得所有

销售订单的列表了：

List<Order> GetSalesOrders()

{

using (EntitiesContainer container = new EntitiesContainer())

{

return (from order in container.Orders

where order is SalesOrder

select order).ToList();

}

简单明了吧？EF带给我们的不仅仅是一个技术框架，也不仅仅是一个数据存取的解决方案。

值对象

EF支持值对象，这很好！在EF中可以定义Complex Types，而一个Complex Type下可以定义多个Primitive Type和多个

Complex Type。与LINQ to SQL相比，这是一大进步。

对于值对象的两点问题我在第一篇文章中已经讲过了，在此就不重复了。

综上所述，EF基本上能够支持领域驱动设计的思想（即使有些方面不完善，但目前也可以找到替代的方案）。我想，只要能

够对领域驱动有清晰的认识，就能够很好地将实体框架应用于领域驱动的实践中。

EntityFramework之领域驱动设计实践（四）

存储过程 - 领域驱动的反模式

EntityFramework（EF）中有一项功能，就是能够根据数据库中的存储过程生成实体的行为（或称方法，以下统称方法）。我

在本系列的第一篇博文中就已经提到，这种做法并不可取！因为存储过程是技术架构中的内容，而我们所关注的却是领域模

型。

Andrey Yemelyanov在其“Using ADO.NET EF in DDD: A Pattern Approach”一文中，有下面这段话：

In this context, the architect also identified the anti-pattern of using the EF (ineffective use): the EF is used to mechanically

derive the domain model from the database schema (database-driven approach). Therefore, the main topic of the guidelines

should be the domain-driven development with the EF and the primary focus should be on how to build a conceptual model

over a relational model and expose it to application programmers.

黑体部分的意思是：（被采访的架构师）同时也指出了使用EF的一种“反模式”，即通过使用数据库结构来机械化地生成领域模

型（数据库驱动的方式）。这也就证明了我在第一篇文章中指出的“只能通过领域模型来映射到数据模型，反过来则不行”的观

点。

我能够理解很多做系统的朋友喜欢考虑数据库方面的事情，毕竟数据存储也是软件系统中不可或缺的部分（当然，内存数据库

另当别论），数据库结构设计的好坏直接影响到系统的运行效率。比如：加不加索引、如何加索引，将对查询效率造成重大影

响。但请注意：你把过多的精力放在了技术架构上，而原本更重要的业务架构却被扔到了一边。

什么时候选择存储过程？我认为存储过程的操作对象应该是数据，而不是对象，业务层也不可能把业务对象交给数据库去处

理。其实，存储过程本身的意义也就是将数据放在DB服务器上处理，以减少客户程序与服务器之间的网络流量和往返次数，

从而提高效率。所以，可以把查询次数较多的、与业务无关的数据处理交给存储过程（比如数据统计），而不要单纯地认为存

储过程能够帮你解决业务逻辑问题，那样做只会让你的领域模型变得混乱，久而久之，你将无法应对复杂的业务逻辑与需求变

更。

在做技术选型的时候还要注意一点，也就是存储过程的数据库相关性。存储过程是特定于某种关系型数据库机制的，比

如，SQL Server的存储过程与Oracle的存储过程并不通用，而有些数据库系统甚至不支持存储过程。因此过多使用存储过程

将会给你带来一些不必要的麻烦。我个人对是否使用存储过程给出如下几点意见：1、根据需求来确定；2、不推荐使用；3、

出于效率等技术考虑，需要使用的，酌情处理。

回过头来看实体框架，虽然现在支持从数据库存储过程生成实体方法的过程，但这是一种反模式，我也不希望今后EF还提供

将实体方法映射到存储过程的功能，因为行为不同于数据，数据是状态，而行为是业务，它与领域密切相关，它不应该被放

到“基础结构层”这一技术架构中。

EntityFramework之领域驱动设计实践（五）

聚合

聚合（Aggregate）是领域驱动设计中非常重要的一个概念。简单地说，聚合是这样一组领域对象（包括实体和值对象），这

组领域对象联合起来表述一个完整的领域概念。比如，根据Eric Evans《领域驱动设计》一书中的例子，一辆车包含四个轮

子，轮子离开“车”就毫无意义，此时这个联合体就是聚合，而“车”就是聚合根（Aggregate Root）。

从实践中得知，并非领域模型中的每个实体都能够完整地表述一个明确的领域概念，就比如客户与送货地址的关系。假设在某

个应用中，系统需要为每个客户维护多个送货地址，此时送货地址就是一个实体，而不是值对象。那么这样一来，领域模型中

至少就有了“客户”和“送货地址”两个实体，而事实上，“送货地址”是针对“客户”的，离开“客户”，“送货地址”就变得毫无意义。于

是，“送货地址”就和“客户”一起，完整地表达了“客户可以有多个送货地址，并能对它们进行维护”的思想。

在《实体框架之领域驱动实践（三） - 案例：一个简易的销售系统》一文中，我们简单地设计了一个领域模型，其中包含了一

些必要的实体和值对象。现在，我用不同颜色的笔在这个领域模型上圈出了三个聚合：客户、订单以及产品分类，如下图所

剩余30页未读，继续阅读

weixin_38586186

粉丝: 9
资源: 943

EntityFramework领域驱动设计实战指南：从疑问到解决方案

封装ef基类框架

【全网首发】EntityFrameWork（EF）6.x 仓储扩展帮助类

ADO.NET EntityFramework 完整版教程（从初级到高级）

EntityFramework与领域驱动设计实战

EntityFramework模型在领域驱动设计界定上下文中的应用

EntityFramework领域驱动模型-陈晴阳大哥的文章.pdf

EntityFramework领域驱动设计实战指南与常见问题解析

深入学习EntityFramework：与领域驱动设计的完美结合

领域驱动设计：分割Entity Framework模型与界定上下文

深入实践Entity Framework Core 2nd版

最新资源