领域驱动设计之代码优先-领域层设计-5 （翻译）

3.1.- 实现领域实体

第一步我们要选择实现领域实体的技术。实体用来保存和管理应用中的主要数据和逻辑。简言之，领域实体

包含并通过属性来获得值，同时也可以有实体内部业务逻辑的类。

下面的子图我们着重了领域层中实体的位置：



决定是否什么类型的数据/技术作为领域实体是非常重要的因为这影响了一些方面，例如这些问题：

- 领域层是否独立于数据访问技术？可以不使用现在的数据访问技术而开始使用不同的而继续使用领域实体类？

问题的答案会根据领域实体类的类型大不相同。例如，如果使用DataSet作为实体，那我们不会轻易的改变数据

访问框架，因为那需要应用的完全的重构，也会影响到应用的核心领域层。

- 在我们不使用DTO，领域实体传送到表现层时，实体类型的选择会更挑剔，因为会处理关于互操作性的问题和

Web服务的序列化问题等。此外，设计和技术的选择会很大影响到领域层的性能和效率。

数据/格式/技术类型的选项：

- POCO 类

上面提到的，实体会由简单的.NET类实现。POCO类最重要的规则是不能有对于其他组件或者类的依赖。例如，

一个典型的EF1.0实体不是POCO，由于它依赖于EF实体的基类。然而，在EF4.0中可以使用纯的POCO类，完全不

依赖于EF。因为这些POCO类适用于面向领域设计，我们会在本章的后面深入这个话题。

在实体框架(EF)中，POCO实体可以手动创建或者由代码生成器生成。

- EF 4.0自跟踪实体

EF 4.0自跟踪实体(STE)是实现一些EF4.0所需接口的对象。更具体写，这些接口是IObjectWithChangeTracker

和INotifyPropertyChanged。这些接口并不属于某个持久化框架。IObjectWithChangeTracker由STE T4模版生成，

INotifyPropertyChanged是标准.NET库的一部分。因此，这些接口并不依赖于除了.NET的任何框架。

自跟踪实体类多于多层架构和中型应用非常方便，客户端的代码应该基于.NET或Silverlight来支持实体改变

跟踪和乐观并发。

- DataSets和DataTables (基础的ADO.NET类)

DataSets类似于离线内存中的数据库。DataSets的使用是典型的.NET应用。DataSets的优点是容易使用，在

大型面向数据的情景或CRUD应用中效率高。”LINQ to DataSets”也可以用来和DataSets使用。

然而，DataSets有重要的缺点，应该认真考虑：

1.- DataSets对非微软平台的兼容性差。尽管可以序列化为XML，但是在使用Web服务的时候可能会导致问题。

2.- 即使在不需要和其他平台兼容的情况，也不建议在Web服务中使用DataSets，因为DataSets是重量级的对象，

尤其在序列化为XML时。使用轻量的POCO类、STE类时Web服务的性能会更高。因此，我们不建议使用DataSets

在Web服务中跨越边界。

3.- ORMs不支持DataSets。

4.- DataSets不是设计用来展现纯的包含领域逻辑的领域实体。DataSets不适合面向领域驱动的架构因为最终

会导致“贫血领域”，领域逻辑和领域数据分开。因此，DataSets不适合领取驱动设计的架构。

- XML

一般我们倾向于使用XML如果表现层需要XML或者领域逻辑必须和XML内容相关。另一个XML的有点是具有简单的

格式化的文本。

　　例如，一个系统中经常用远程系统的消息，消息是基于XML文档的节点。记住XML的使用和操作需要大量的内存

资源；如果XML的量很高，访问和处理XML会成为处理XML文档标准API的瓶颈。

　　使用基于XML的实体的最大问题是非面向领域的，因为会是贫血领域。因此使用XML也不适合领域驱动设计。

表 12.-　领域实体规则

规则 Nº: I5. 一般情况，领域实体由POCO或自跟踪实体实现

o 规则

- 按照上面的考虑事项，由于架构是面向领域，我们应该实现最大化的独立，领域实体会由POCO类或STE实现。

在EF 4.0中，这些由T4模版生成，会节省很多实现。

- 手工创建它们也可以，甚至是更纯的领取驱动设计方法，但会有更多的工作处理乐观并发等。

使用POCO实体的优点

- 它们独立于特定的类库。

- 它们相对轻量，可以提供很好的性能。

- 它们是最适合领域驱动设计的架构

什么时候使用EF自跟踪实体

- 在大部分应用中使用STE也是推荐的，因为STE比POCO实体更有效。STE在多层应用中提供了非常简单的

乐观并发控制管理。客户端应用需要是基于.NET或Silverlight。

- STE适合于那些我们完全控制的开发。它不适用于不共享真实数据类型的应用；例如在SOA应用中，我们

只控制一端。这种情况下，不可能也不允许共享数据类型，建议在分发服务层中使用DTO。

什么时候使用POCO实体

- 反之，如果我们的应用是面向SOA，只能使用DTO，我们将管理并发维面。在这些情况建议使用POCO领域实体。

使用POCO会有非常简单的实体，虽然我们会将在系统的实现付出更大的努力。

参考

实体框架中的POCO：
http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx
实体框架中的自跟踪实体：
http://blogs.msdn.com/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx