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)。