使.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）。

你需要考虑的应用程序结构框架中的最后一步就是测试过程。测试在开发阶段很重要，因为它是证明软件可行的唯一的方式。然而，在时间紧迫的情况下，比如发行日期快到了，测试通常似乎处于一个次要位置。而且在大多数情况下，测试这项工作需要人们精力集中、担负责任。每次代码改变时，都需要人们严格地重复测试过程。

一种新的软件开发方法学，极端编程（extreme programming），引进了一个严格的软件开发方法，这种方法牢记使最终产品可以交付、使用户满意并质量合格（见资源）。它是建立在一个基于测试的开发理念上的，鼓励开发人员在编写实际的功能代码前，编写测试用例。所有的测试用例都作为类来开发，它们测试商业功能类的功能性。

一旦将测试用例作为类，你就可以在任何时候重复测试。如果所有的测试用例都不能运行，你就会知道有问题。当现有的代码被改变时（很可能有些东西被破坏），这种测试方法尤其有效。

为了使测试更容易，极端编程方法的创立人Kent Beck创建了一种简单的称为JUnit的框架，使人们可以用Java编写测试用例。作为.NET程序的“工厂”，你可以运用同等的公开的资源NUnit（见资源）。它是建立在JUnit的最初观念上的，你可以把它同Visual Studio .NET（VS.NET）集成起来。它可以让你在同一个项目中包含测试类和功能类。在相同的项目中拥有测试类和功能类就可以进行有效的测试。每次当一个功能类改变时，你不需要转换项目来测试。在开发周期中，你将测试方法添加到测试用例类，并添加功能到商业类，然后运行测试用例。测试类也同商业类一起集成在Visual SourceSafe中。当你将测试作为开发过程的一个不可分割的部分时，你的代码质量就提高了，重复测试很简单。它也消除了由于改变代码而引起的恐惧。

现在你已经知道了建立一个公共的应用程序结构的步骤，你已经做好准备将它们用于你的企业了。建立一个积极的小组，让它们负责公共的底层框架及其前景。每个企业都会构建自己的应用程序并为此投资。创建一个公共的底层框架可以帮你更快地开发更高质量的应用程序，而且投资更少。


关于作者:
Rao Chejarla是一个独立的软件咨询者。他主要关注软件工程方法学和运用.NET Framework和J2EE的应用程序结构。他在软件开发、设计和结构方面已有12年的经验了。他的联系方式是kotrao@yahoo.com。

上一个：使.NET应用程序开发标准化（转）
下一个：模式与XP(好文转)