DotNET应用架构设计指南（第二章：设计应用程序和服务组件（11-14））

 

设计数据层

几乎所有的应用程序和服务都需要存储和访问某些类型的数据。例如，在本指南中讨论的零售应用程序需要存储产品，客户和订单数据。

 

当与数据发生作用时，需要决定：

l 正在使用的数据存储。

l 组件的设计常考虑访问数据存储。

l 组件之间传递的数据格式，和它需要的编程模式。

 

应用程序或者服务可以拥有一个或者多个数据来源，这些数据来源可能是不同的类型。这个常使用一个数据源访问数据的逻辑将被封装在数据访问逻辑组件，为查询和刷新数据提供方法。应用程序需要起作用的数据是和真实世界的实体相关，它们参与业务的一部分。在一些场景下，可以使用自定义组件表现这些实体，在其它情况下，可以直接选择使用ADO.NET的Dataset或者XML文档。

 

图2.11显示了应用程序的逻辑数据层是由一个或者多个数据存储组成的方式，及描绘了数据访问逻辑组件如何被用于获取和维护这些数据存储的数据。

 

图2.11 数据组件

 

许多应用程序使用关系数据库作为为应用程序提供数据的关键数据存储。另外可以选择的有：Microsoft Exchange Server Web存储，传统（legacy）数据库，文件系统，或文档管理服务。

 

当应用程序从数据库获取数据时，可以是用如DataSet或者DataReader类似的数据格式。然后，数据将遍及应用程序的层被转换，最后，将被其中的一个组件所操作。可以使用不同的数据格式进行获取，传递和操作数据；例如，可以使用DataSet中的数据来设置自定义实体对象的属性。然而，应该努力保持格式的一致性，因为这样，或许可以改善性能和应用程序的可维护性，应用程序仅有有限的格式，避免了额外的转换层和对不同API的学习。

 

下面章节讨论数据存储的选择，数据访问逻辑组件的设计，展现数据的有效选择。

 

数据存储

存储的一部类型包括：

l 关系数据库。如SQL Server数据的关系数据库提供高数量，转换，高性能数据管理，同时，具备安全，运行和数据转换能力。关系数据库也存储过程中托管复杂的数据逻辑指令和函数，可用于为数据高精密的业务处理提供直接有效的环境。SQL Server也提供桌面和手持设备版本，让你为数据访问逻辑组件使用很清晰的实现。数据库设计超出了这个指南的范围。更多数据库设计明细，见SQL Server 2000 SDK里的“Database Design Considerations” （(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_62ur.asp)。

l 消息数据库。可以把数据存储在Exchange Server Web存储中。如果应用程序是以群集（groupware）为中心，以工作组（workgroup）为中心，或者以消息为中心，并且，不想依赖需要被隔离管理的其它数据存储，这个存储方式是最有效。然而，相对于成熟的关系数据库管理系统，消息数据存储典型的是低性能的，低可度量的，低有效的和低管理能力。因此，提供在消息产品的数据存储的使用的应用程序是和非常情况有关的。有关开发Exchange Server的数据存储的信息，见MSDN上的“Developing Web Storage System Applications” (http://msdn.microsoft.com/library/en-us/dnmes2k/html/webstorewp.asp)。

l 文件系统。可以决定存储数据在自己的文档中。这些文件是自己的格式或者有应用程序期望的架构定义的XML文件格式。

 

有许多其它的存储（如ＸＭＬ数据库，在线分析处理服务，数据仓库等等），但他们超出了本指南讨论的范围。