DotNET应用架构设计指南（第二章：设计应用程序和服务组件（10-13））
Posted on 2009-03-04 15:55 Abbott zhao 阅读(192) 评论(0) 编辑 收藏 举报表现数据和通过层传递它
当数据访问逻辑组件返回数据时，他们可以使用一批的数据格式。这些格式来源于不同的数据为中心（例如，一个XML字符串），这些数据中心更多是面向对象（例如，封装业务实体的自定义组件）。返回数据的一部格式有：
l XML
l DataReader
l DataSet
l 类型化的DataSet
l 自定义对象，使用属性映射数据字段，通过数据访问逻辑组件执行数据修改的方法。
有关应用程序设计中对选择有效的数据格式的更多信息，见MSDN上的“Designing Data Tier Components and Passing Data Through Tiers” (http://msdn.microsoft.com/library/?url=/library/en-us/dnbda/html/BOAGag.asp?frame=true)。
选择的数据格式依赖于想用数据如何工作。建议避免设计要求在自定义面向对象格式中转换数据，因为这样做，需要自定义序列化实现和造成性能负担。一般情况下，使用一个更好的数据为中心格式，如DataSet，从数据访问逻辑组件到业务层传递数据，如果想使用面向对象的方式的数据来工作，就使用它合成一个自定义的业务实体。尽管，在许多情况下，用DataSet用在业务数据更简单。
使用自定义业务实体组件表现数据
在许多情况下，会直接使用ADO.NET的dataset或者XML文档进行工作。这个不需要必须写任何自定义代码就可以在应用程序层之间传递结构化的数据。然而，如果想封装与指定的格式起作用所有明细；或者，想增加行为到数据中，需要开发自定义对象。这个授予你对其它应用程序组件可能与数据交换到什么程度的紧密控制，允许抽象来源于应用程序使用的数据架构的内部格式，能够增加行为到数据中。这个指南把用于表现数据的组件叫做“业务实体”。
例如，以前讨论的订购处理，可以使用一个Order对象，有一个相关Customer对象，和LineItem对象的容器。这些组件构成了应用程序的一部分，可能被其它业务组件或者表现层组件使用。
实体组件包含快照数据。它们是信息的有效本地缓存，因此，如果数据被读入一个激活的事务处理上下文环境中，这些数据是仅有的一致性保证。不应该映射一个业务实体到各自的数据库表；典型的是，一个业务实体将拥有一个基本架构的反向格式化的架构。注意，实体可以表现从许多来源集合的数据。
因为组件存储数据值，并通过属性暴露它们，所以，提供正式化程序访问业务数据和相关的功能。应该避免这样的一种情况设计业务实体组件，数据存储不应每一次访问都引起属性变化，而应该提供一个Update方法，传播（propagate）所有不本地改变放回到数据库。业务实体组件不直接访问数据库，但，当它们方法被调用时，应该使用数据访问逻辑组件执行数据相关的工作。业务实体不应该启动任何类型的事务处理，不应该使用数据访问API—它们仅是数据的展现，暗含的行为。因为它们会和用户界面一样可以被业务组件调用，所以，它们很明显地随着事务流动，不表决任何正在进行的事务。
可以设计业务实体组件为可序列化，允许持久化当前状态（例如，如果工作在离线下，可以储存在本地磁盘，或者放入消息队列消息中）。
业务实体组件在面向对象程序和基于文档开发模式之间进行简单的过渡。尽管在文档交换期间业务功能和事务处理更容易表达，但，在正式的环境里，面向对象设计是是普遍的，如，用户界面设计。
注意：自定义业务实体组件不是所有应用程序必须强制的一部分。许多解决方案（特别是基于ASP.NET应用程序和组件）不使用自定义的业务实体表现，对应是使用DataSet或者XML文档，因为他们提供了必须的信息，相对于面向对象，开发模式更具备基于任务和文档。
业务实体组件接口设计
业务实体组件需要暴露：
l 为实体属性（attribute）设置属性（property）访问器（get和set功能）。
l 为相关数据的子集设置集合访问器。（集合不一定产生业务实体的集合，所以，可以设计服务实体来直接暴露DataSet或者DataTable，不和对象模式的横断面相关。）
l 一般情况下，在实体管理中控制功能和属性，例如，加载，保存，判断是否改变，和验证。
l 访问实体的元数据，可以有用于改善用户接口的可维护性。
l 发信号通知的事件在下层数据中变化。
l 执行业务任务的方法，或者为复杂请求获取数据。这些方法可以仅作用于本地数据（例如，Order.GetTotalCost），或者作用在业务组件和和处理中（例如，Order.Place）。
l 为数据绑定设置方法和接口。
业务实体组件的使用者包括：
l 富客户端的用户交互组件。这些可以绑定业务实体组件，或者被组件暴露的任何查询的数据。UI控制器功能也可以为数据的输入和显示设置业务实体的set和get属性。
l 用户处理组件。用户处理组件可以保存一个或更多的业务实体，作为它们内部特定的业务状态的一部分。
l 业务组件。业务处理可以把一个业务实体作为一个参数传递给数据访问逻辑组件的方法（例如，Order对象可以被传递给数据访问逻辑组件的InsertOrder方法）。可供选择的是，业务组件也可以使用业务实体访问数据的行为（例如，通过调用一个Order对象的Place方法，在这个方法中，依次传递订单数据到数据访问逻辑组件），但是，这个方法相对于直接传递业务实体给数据访问逻辑组件，是很少见的，因为，伴随着基于对象的模式，它混合了功能、面向文档的模式。
业务实体设计建议
这些建议将帮助你实现展现数据的正确的机制：
l 小心考虑是否需要自定义实体代码，或者需要其它数据表现。编码自定义实体是个复杂的任务，随着特征的数量增长，不断增加开发成本。特别是，为应用程序实现的自定义实体需要暴露自定义宏，或者为自定义开发者熟悉的脚本对象。
l 通过一个基类导出实现的业务实体，这个基类提供样本功能和封装一般的任务。
l 对应复杂数据，依赖于保存在内部的DataSet或者XML文档，而不是内部集合，结构等等。
l 实现一批横跨业务实体的公共接口，暴露一般的功能：
Ø 控制方法和属性，如，保存，加载，删除，是否数据变化和验证。
Ø 元数据方法。如，getAttributesMetadata, getChildDataSetMetadata,和getRelatedEntitiesMetadate. 这些特别有用于用户界面设计。
l 当作元数据隔离验证规则，例如，通过暴露XML架构定义语言（XSD）架构。确保，外部调用者不能破坏这些验证规则。
l 业务实体应该验证它们封装的数据，这些验证通过一系列的强制（enforcement of continuous）和及时点（point-in-time）验证规则。
l 围绕数据，在基于架构的实体和业务规则之间实现的暗含的强制关系。这样做，允许在一个地方，实现所有的数据访问策略和业务逻辑相关的策略。如果业务实体直接访问SQL Server数据库，意味着部署到客户端的应用程序使用业务实体将需要SQL链接和登陆权限。
当开发业务实体组件时，需要应更明确设计建议和简单的例子来帮助你，见MSDN上的“Designing Data Tier Components and Passing Data Through Tiers” (http://msdn.microsoft.com/library/?url=/library/en-us/dnbda/html/BOAGag.asp?frame=true).
