NET 应用架构指导 V2 学习笔记（二十一） 设计业务实体

　　概况

　　业务实体存储数据，通过属性暴露数据，包含并管理应用需要用的数据，同时提供编程访问及相关的功能。业务实体应该在内部进行数据有效性验证，并且封装业务逻辑来保证一致性，实现业务规则和行为。因此，设计适当的业务实体，对于最大化性能和高效性的业务层来说，是非常重要的。

　　本章将帮助你理解业务实体组件的设计。首先，看看应用中使用的不同数据格式，以及数据被如何使用。接下来，你将会学到，在设计中，已有的数据格式决定决定业务规则的实现。最后，你将会学习设计自定义对象，如何支持不同格式的序列化。

　　设计步骤

　　1 选择表现形式

　　本节你会看到业务实体的多种表现形式，每一种的好处和能力，为你的方案选择正确的表现形式。常用的表现形式包括下面的几种：

• 　　自定义业务对象。例如，ADO.NET Entity Framework 、HNibernate这类的ORM技术可以用来创建自定义对象。你也可以手动创建它们。如果你需要在数据中封装复杂的业务规则和行为，自定义对象较为合适。如果你需要应用程序跨域、进程、物理边界访问自定义对象，你可以使用DTO实现一个服务层来操作自定义对象。
• 　　DataSet or DataTable。数据集是一种内存形式的数据库，通常和实际的数据库有映射关系。如果你不用ORM，创建一个数据为中心，业务逻辑非常少的应用的话，可以考虑使用DataSet。数据集不能扩展封装业务规则。尽管数据集可以序列化为xml，但是不应该跨进程或者是服务边界暴露它们。
• 　　XML。是一种结构化数据的标准格式。但是要小心，使用和操作xml将会消耗大量的内存资源。

　　2 为业务实体选择一个设计

　　如果你决定要自定义对象为业务实体的表现形式，下一步就是设计这些对象。设计自定义对象的方法是以使用对象的计划为基础。例如：领域模型实体要求对业务模型的深度分析，数据表模型实体要求理解数据库结构。常用的设计方法包括：

• 　　领域模型，是一种面向对象的设计模式。领域模型设计的目的是设计一个符合真实世界的业务实体。在使用领域模型进行设计的时候，业务实体通常包括行为和结构。换句话说，业务规则和关系被封装在领域模型中。需要深度分析业务领域，很多时候和数据库都没有映射关系。如果你的业务规则复杂，考虑使用领域模型设计。
• 　　数据表模型。也是以一种面向对象的设计模式。对象化的表模型设计，基于数据库和表结构定于实体。如果你的业务逻辑是操作单表和视图的话，或者是实体和数据表非常相似的话，考虑使用数据表模型。
• 　　
• 　　自定义XML。代表序列化之后的xml数据。

　　在使用自定义对象的时候，不是全部都用一种表现形式。例如：有复杂业务规则的时候可以用领域模型设计。简单的时候，就可以用xml对象或者是数据表模型。

　　3 决定序列化支持

　　你一定要决定业务实体如何跨越边界传输。在大部分情况，跨越物理边界（应用程序域、进程、服务接口边界）传输，需要序列化数据。在跨越逻辑边界的时候，你也可以序列化数据，但是要考虑带来的性能影响。业务实体常用的传输选择：

• 　　如果有需要的话，直接暴露序列化的业务实体。如果应用的另外一个层，是在同一个物理层的，需要消费业务实体，通常的做法是直接暴露序列化的业务实体。但是，缺点就是在业务实体的消费者与实体的实现之间创建了依赖关系。因此，不推荐这个方法，除非你可以维护业务实体的消费者，并且不需要对业务实体进行远程访问。
• 　　将业务实体转换为可序列化的Data Transfer Object。从内部的业务层实现中解耦数据的消费者，考虑将业务实体翻译为可序列化的DTO。DTO是一种设计模式，用来跨边界传输，将多个数据结构打包为单个数据结构。当你的业务实体消费者的数据表现形式和你不一样的时候，DTO非常有用。这个方法对于内部业务层的修改不影响数据的消费者，允许你更容易修订自己的接口。这个方法适用于有外部客户端消费数据的情况。
• 　　直接暴露XML。在某些情况，你可以直接将业务实体序列化为xml。

　　领域驱动设计DDD

　　Domain Driven Design是一种基于领域模型、元素和行为、他们之间的关系的面向对象软件设计方法。目标是将软件系统看做是定义了领域模型的真实业务模型。

　　如果要应用DDD，一定要对业务模型有很好的理解，在业务语言方面经验丰富。开发团队需要经常和领域专家一起工作。架构师，开发者，领域专家有不同的知识背景，在很多时候用不同的语言描述他们的目标，设计和需求。但是，在DDD中，团队用同一个语言描述业务模型。

　　未完待续。。。。。。。。。。。。。。。。。。。。。。。。