VS2005数据存取层深入剖析高级篇

　　二、 生成代码评价

　　值得注意的是，围绕DataSet和BindingSource组件生成的代码使用了中断连接模型和普通的T-SQL语句。这并不是说，不管你是通过Visual Studio 2005向导编辑代码或是手工编辑，都可以毫无顾忌地使用存储过程和事务。

　　这里所使用的中断连接模型要求：在表单启动时，所有的数据都必须已经被加载到内存中。但是，在这种情况下，你仍然能够自由地编辑自动生成的代码，例如使应用程序仅加载它在运行时刻需要的数据。默认情况下，一个使用Visual Studio 2005数据设计器生成代码的数据绑定表单的Load事件看起来如下所示：

Sub NorthwindForm_Load(ByVal sender As Object， _ ByVal e As EventArgs) Handles MyBase.Load CustomersTableAdapter.Fill(nwDataSet.Customers) //………… End Sub

　　Visual Studio 2005在绑定的DataSet组件内相应于每个表格适配器放入了一个对Fill方法的调用。

　　须知，Visual Studio 2005生成的代码将同工程的其它部分一起编译。在无法完全满足你的需要和要求时，决不应该相当然地使用这些代码。你可以自由地修改它；但是，在这样做之前，你首先应该深入理解它的逻辑与结构。不要相当然认为，一个向导能为你实现一切或者干脆放弃使用之。你应该接受它，然后修改之以适合你的需要。大多数时候，这是你必须做的，当然也是最明智的选择。

　　三、 DAL通用模式

　　任何相当复杂的系统都要求实现许多不同层来存取和操作数据。比如，你可以使用业务逻辑层(BLL)来与用户接口进行通讯并且提供安全检查、数据校验以及其它服务，例如数据的预处理和事后处理等；另一方面，你可以使用数据存取层(DAL)来存取和检索数据。其实，该DAL仅是一个合并了API功能实现数据库存取的组件。CRUD部分的任务相应于一个DAL部分的目标，也即是把数据暴露给业务层以便实现数据交换。这些层按特定顺序“迭放”在一起；DAL层由BLL层使用，并且不应该被用户接口所利用以免打破各层之间的分离原则。

　　当你想创建一个库以便合并数据存取功能时，你该怎么办呢？是否应该使用Visual Studio 2005数据设计器所提出的定制的基于表格的方法？或是具有较好的条件而使用一个商业性的O/R映射器工具来生成大多数代码？还是打算自己开发DAL？幸好，这些选择并非互斥的，完全可以根据需要进行混合使用。于是，问题出现了：你应该怎么办？现在，让我们首先来理解通用模式。在这样做时，你还是应该首先搞清楚Visual Studio 2005所提供的方法和逻辑。

　　一般地，在设计一个实现数据处理系统的后端时，通常使用两种主要模型：Domain模型和Table模型。
Domain模型构画了一个对象模型，其中，每一个实体都是通过合并了特定行为和数据的ad hoc类进行描述的。一个类的任何实例都相应于该模型中一个特定的实体；关系是通过跨越所涉及的类的属性进行表达的。

　　【译者注】 类似于图书馆里的书籍检索，即书籍库(数据库)相对稳定不变，不同用户的查询要求是千变万化的，这种检索就称为“ad hoc”。基于Web的搜索引擎也属于这一类。

　　在Table模型中，你要为目标数据库中的每个表格定义一个类。任何要求处理数据的代码都是在单个类的实例上定义的。总结来说，如果你的数据模型中包括一个Order实体，那么，你应该使用域模型为每一个订单创建一个OrderEntity对象，还有一个OrderManager对象用于使用表格模型来处理所有的订单。很容易看出，该“订单管理器”对象十分类似Visual Studio 2005设计器中的表格适配器对象。
　
　　在Domain模型和Table模型抽象模型中，你可以发现各种具体的设计模式。在大多数流行的设计模式中，主要使用的是数据映射器和表格数据网关(TDG)。

　　四、 应用数据映射模式

　　一个数据映射(DM)对象负责把从表格中提取的原始数据加载到内存对象（这些对象被更为紧密地映射到更高一级：实体-关系数据模型）。该DM模式尤其适合于复杂的域逻辑领域—此时数据的物理结构必须被加以提取以便直接编码、简化阅读和确保恰当的维护费用。典型地，一个高度复杂的逻辑一般都有一些额外要求，例如多数据库支持和严格的单元测试等。在两种情况下，不同的系统发布，或开发周期中的不同步骤，可能要求替换整个数据映射层以便应用一种不同的逻辑，针对不同的目标数据库，或是仅为了实现测试目的。你进行越多的抽象并且在系统中进行越多的分层，那么以后对于你以及你的客户将越发有益。

　　毋庸置疑，该DM模式有时看起来有些过于复杂，但对于丰富的而复杂的系统来说一定是一种可行的选择。一种更为简单的变种，特别适合于简单的逻辑实现，就是活动记录模式。

　　在一种DM情况下，你需要为抽象数据模型中的每一个实体创建许多类。你将创建一个实体类（也许一个类型安全的集合类）和一个管理器类来为DAL提供公共入口点。列表5展示了一些具体的示例代码。

　　列表5.DM模式(Employee实体)的示例代码。

Public Class Employee 　Public ID As Integer 　Public FirstName As String 　Public LastName As String 　//…… End Class Public Class EmployeeCollection : Inherits Collection (Of Employee) End Class Public Class EmployeeManager 　Public Function FindAll() As EmployeeCollection 　Public Function Find(ByVal empID As Integer) As Employee 　Public Sub Update(ByVal emp As Employee) 　Public Sub Insert(ByVal emp As Employee) 　Public Sub Delete(ByVal emp As Employee) 　Public Sub Delete(ByVal empID As Integer) 　Public Function FindOrders(ByVal empID As Integer) _ 　As OrderCollection 　//…… End Class

　　这个EmployeeManager类中提供的方法实现怎么样？不管在你的设计中引入了多少的抽象，在某种程度上你都需要手工实现连接字符串，ADO.NET命令和事务等内容。当然，你能够把这部分代码直接插入到EmployeeManager的方法体内。然而，还有一种更好的方法就是，使用一组基于TDG模式的中间集合类来实现这一点。图7展示了整个实现框架。

图7.一个使用了模式的多层应用程序架构。

　　其基本思想是，由描述层创建一个给定实体（比如说，employee表格）的管理器类的实例。一方面，该管理器类要对描述层暴露高级对象；另一方面，它还负责连接到底层DAL以便进行物理数据存取。在该管理器和DAL可能存在各种层。为了实现更多的灵活性，你可能想使用一种可替换的工厂机制并且是针对不同的数据库的。

　　反过来，从描述层对管理器类的调用将会实例化一个数据存取提供者工厂类。这个类将从配置文件信息(类和程序集)中读取关于该工厂类的信息以便用来创建其支持的实体(如雇员，顾客，产品，订单等)的数据提供者。

　　每个工厂类都要实现一个合同接口—该接口将依赖于一个方法来返回针对各种实体的数据提供者。最后，这些数据提供者要实现一个接口以便与管理器类中的方法相匹，并使用TDG模式来得到/设置一特定数据库中的物理数据。

　　基于这一模式，通过简单地改变一下配置文件内的某个入口，你就可以使整个系统工作在一个完全不同的数据库之上。现在，你有了一些类—数据提供者—你可以在其中编写优化的数据库代码—并且由于使用了基于合同的接口，所以你不必去打破与上一层的关系。

 

上一页  [1] [2] [3] 下一页