【转】EntityFramework之领域驱动设计实践（三）

原文地址：http://www.cnblogs.com/daxnet/archive/2010/07/07/1772593.html

案例：一个简易的销售系统

从现在开始，我们将以一个简易的销售系统为例，探讨EntityFramework在领域驱动设计上的应用。为了方便讨论，我们的销售系统非常简单，不会涉及客户存在多个收货地址的情况，也不会包含任何库存管理的内容。假设我们的系统只需要维护产品类型、产品以及客户信息，并能够帮客户下订单、跟踪订单状态，以及接受客户退货。从简单的分析我们大致可以了解到，这个系统将会有如下实体：客户、单据、产品及其类型。单据分为销售订单和退货单两种，每个单据可以有多个单据行（比如销售订单行和退货单行）。不仅如此，系统允许每个客户有多张信用卡，以便在结账的时候，选择一张信用卡进行支付。在使用EF 的Entity Data Model Designer进行设计后，我们得到下面的模型：

上面的模型表述了领域模型中各个实体及其之间的关系。我们先不去讨论整个系统的业务会是什么样的，我们先看看EF是如何支持实体和值对象概念的。

实体

首先看看实体这个概念。在领域驱动设计的理论中，实体是模型中需要区分个体的对象，也就是说，针对某种类型，我们既要知道它是什么，还需要知道它是哪个。我在前面的博文中有介绍过实体这个概念。实体都有一个标识符，以便跟同类型的其它实体进行区分。EF Entity Data Model Designer上能够画出的都是实体，你可以看到每个实体都有个Id成员，其Entity Key属性被设置为True，同时被分配了一种标识符的生成方式，如下图所示：

在从领域模型映射到数据模型的过程中，这个标识符通常都是被映射为关系数据库某个数据表的主键，这个应该是很容易理解的。

其次，EF不支持实体行为，因此，整个模型只能被称为Entity Data Model，而不是Entity Model，因为它只支持对实体数据的描述。幸亏从.NET 2.0开始，托管语言开始支持partial特性，同一个类可以以部分类（partial class）的特性写入多个代码文件中。因此，如果需要向上述模型中的实体加入行为，我们可以在工程中加入几个代码文件，然后使用部分类的特点，为实体添加必要的行为。比如，下面的部分类向订单行中加入了一个只读属性，该属性用于计算某一单据行所拥有的总金额：

有朋友会问，为什么我们要另外使用部分类，而不是直接在模型文件 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;
```
```
}
```

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

综上所述，EF基本上能够支持领域驱动设计的思想（即使有些方面不完善，但目前也可以找到替代的方案）。我想，只要能够对领域驱动有清晰的认识，就能够很好地将实体框架应用于领域驱动的实践中。

转载于:https://www.cnblogs.com/fcsh820/archive/2010/11/01/1866369.html

【转】EntityFramework之领域驱动设计实践（三）相关推荐

EntityFramework之领域驱动设计实践（十）（转）
http://www.cnblogs.com/daxnet/archive/2010/07/19/1780764.html 规约(Specification)模式本来针对规约模式的讨论,我并没有想将 ...
EntityFramework之领域驱动设计实践（五）
聚合聚合(Aggregate)是领域驱动设计中非常重要的一个概念.简单地说,聚合是这样一组领域对象(包括实体和值对象),这组领域对象联合起来表述一个完整的领域概念.比如,根据Eric Evans&l ...
EntityFramework之领域驱动设计实践（八）
仓储的实现:基本篇我们先从技术角度考虑仓储的问题.实体框架(EntityFramework)中,操作数据库是非常简单的:在ObjectContext中使用LINQ to Entities即可完成操作 ...
苏宁金融会员领域驱动设计实践
苏宁金融会员领域驱动设计实践背景介绍近年来,苏宁集团业务不断扩大,用户快速增长,线上线下融合不断深入,系统的复杂性越来越高,技术的广度和深度都在不断拓展. 在整个集团技术不断迭代演进的过程中,集团 ...
DDD 领域驱动设计－三个问题思考实体和值对象（续）
上一篇:DDD 领域驱动设计-三个问题思考实体和值对象说实话,整理现在这一篇博文的想法,在上一篇发布出来的时候就有了,但到现在才动起笔来,而且写之前又反复读了上一篇博文的内容及评论,然后去收集资料, ...
【DDD】领域驱动设计实践 —— UI层实现
前面几篇blog主要介绍了DDD落地架构及业务建模战术,后续几篇blog会在此基础上,讲解具体的架构实现,通过完整代码demo的形式,更好地将DDD的落地方案呈现出来.本文是架构实现讲解的第一篇,主要 ...
领域驱动设计实践（一）（转）
分层构架在分析领域驱动设计之前,我们需要先回顾以前的分层架构."层"是一种体系结构模式,也是被广大软件从业人员用的最为广泛而且最为灵活的模式之一.其中最为大家所熟知的就是三层架构 ...
薪水支付系统领域驱动设计实践
(一) 通过领域驱动设计想解决什么问题一个系统,按理说针对的行业是固定的,业务也比较接近,可是每次换个用户,总感觉需求变化一点点,系统却要改得天翻地覆.修改后的代码让不忍直视,心里暗暗嘀咕,神 ...
领域驱动设计实践框架-COLA的解读
引言 Cola作为当前比较优秀的领域驱动设计最佳实践框架越来越被更多的技术人所知晓.先抛出COLA 4.0:应用架构的最佳实践_张建飞(Frank)的博客-CSDN博客_cola架构是关于COLA4 ...

【转】EntityFramework之领域驱动设计实践（三）

案例：一个简易的销售系统

【转】EntityFramework之领域驱动设计实践（三）相关推荐

最新文章

热门文章