使.NET应用程序开发标准化2（转）

一旦你得到了适当的安全组件，你就做好准备研究你的数据访问方法了。人们在这方面常犯的错误就是在显示层开发所有的东西，包括你的商业逻辑和数据访问组件。这种开发就导致了很难维护的像意大利面条一样的代码（见资源）。它也使改变数据库的计划或者改变到一个全新的数据库变得很难、很昂贵，因为你必须找到散布在你的应用程序中的所有的单独的数据访问调用指令。用四个层来构建你的企业级的应用程序――显示层、工作流层、商业层和数据访问层――可以使应用程序更容易维护、更具扩展性。
关于这个话题，我将重点讲述数据访问层。应用程序需要将数据访问层同商业对象明显分离开。你不想让SQL语句散布在从显示层到商业层的所有代码中。这些层不需要知道数据是如何得到的，从哪里得到的。
Microsoft包含两个新的对象――Dataset和DataReader――它们作为ADO.NET的一部分来分离各个层。Dataset对象对于一个不连接的应用程序模式是很有用的，而DataReader对象则用于连接的应用程序。然而，这些对象都有一个缺点：当你访问属性的值时，它们或者通过名字或者通过列号来查找。在通过列的名字访问数据的情况下，如果在这些名字中有一个typo，在编译时就不会被检测出来。当列名散布在你的代码中时，就很难在以后改变它们的名字了。如果你通过列号来访问数据，代码更难读，而且你需要知道列在Dataset或DataReader中出现的顺序。
运用Strongly Typed Datasets
强类型（strongly typed) datasets解决了这个问题，但你不能总用Dataset对象。当你运用Dataset对象时，它把所有记录都读进内存中，在大量的应用程序中，服务器资源会用尽。但如果用DataReader，就没有一个等同于strongly typed Row的对象。一种方法就是反复运用Dataset和DataReader，这样会形成强类型的对象，是很理想的。
我用的一种方法就是对每个表用一个Proxy对象和一个Domain对象。Proxy对象包含SQL语句或存储过程调用指令来得到或保存域对象。Domain对象包含属性来体现表的特性。商业逻辑组件与Proxy对象交互，并在Domain对象上执行商业逻辑。这种方法为Proxy对象限制了SQL语句或过程名字的内容。它提供了一个统一的数据访问策略，提高了应用程序代码的可读性，减少了运行时的错误，并提供了灵活性，如果它有必要转换到一个不同的数据库层的话（见图1）。
图1. 显示各个层
我们有必要探讨一下关于Proxy对象更多的细节问题。一个引起人们争议的问题就是在Proxy对象中是运用SQL语句还是运用存储过程调用。运用存储过程比SQL语句更有效。因此一些公司更喜欢用存储过程，但你应该选用更适合你公司的方法。不管你采用什么方法，避免割裂存储过程和商业逻辑组件之间的商业逻辑。我喜欢把商业逻辑保存在商业对象中。作为例子，我提供了一个C#代码列表，它显示了一个Authors表的Proxy和Domain类（见列表2）。