通过为你的企业建立一个公共的应用程序结构框架来提高.NET应用程序的开发效率。
作者：Rao Chejarla （印度）
涉及技术：ADO.NET、ASP.NET
开发企业应用程序是个复杂的过程。你可以运用Microsoft .NET技术的许多工具来使这个过程变得更快更容易，但由于.NET的复杂性，选择最直接的方法是很难的。如果没有明确的标准和方针用来开发应用程序，企业中的每个开发小组就可能在安全、数据库访问策略和测试过程上进行重复开发。虽然每个小组都可能在这些领域中开发出有效的方法，但会导致不必要的重复工作。而且在重要的安全性方面，如果每个开发小组都确定各自的安全实现方法，那么应用程序可能变得很容易受到攻击。
如果你在IT集团公司工作，这种情况的确很常见。幸运的是，你可以把事情简单化。虽然企业中开发的每个应用程序都解决一个独特的商业问题，但你可以将所有的应用程序建立在同样的底层框架组件上。通过开发标准和公从命名惯例到用来强化应用程序结构的预装组件的最好方法。共应用程序结构组件，你的开发小组就可以节省时间、确保应用程序是安全的、并改善各小组间的协作。标准的范围很广，在本文中，我将探讨在企业中实现一个公共应用程序结构框架的最好的方法。我将特别关注三个主要的方面：应用程序安全性、数据库访问策略和测试过程。我将讲述验证你的用户的身份、用四个层来构建你的企业级应用程序、还将讲述一下Microsoft的两个新的对象——Dataset和DataReader——它们是ADO.NET的一部分，可以帮你分离各个层。
运用预装组件是加强应用程序结构并提供一般服务的一个好方法。因为应用程序结构是个企业级的问题，你现有的企业组织结构中可能并没有一个小组来承担这项工作。然而，形成这样一个小组是很简单的，你只需要重新编制各个小组，然后分配一些技术很强的人员（已经在你们公司中）来从事应用程序结构方面的工作。
你在引进一个公共底层框架应用程序时，各小组可能主要关注商业问题，而不是担心结构问题。这就使我们对做每个应用程序的开发人员的技术要求并不高。因此，开发进度就会缩短，可以更好地响应市场情况。所有这些因素的结合就会减少开发和维护方面的投资，最终提高你们公司的赢利。然而，你首先需要在三个主要方面建立一个公共底层框架：应用程序安全性、数据库访问策略和测试过程。
安全是很重要的，你应该从开发的早期阶段就控制应用程序结构的这个方面。适当的用户身份验证和授权可以保证一个应用程序的安全。在没有集中的安全组件的时候，每个小组编写它自己的安全代码，这是很危险的。一个中心安全策略不仅可以使开发人员避免重复劳动，为企业中所有的应用程序提供同样级别的保护，还可以创建一个结构，使所有的修改都在一个地方进行，而且不会产生新的安全漏洞。安全结构中首要的一步就是用户身份验证。
验证你的用户身份
一个典型的企业需要验证两类用户的身份：内部用户（雇员）和外部用户（供应商和客户）。你的企业应该建立统一的策略来验证这两类用户的身份并对他们授权。
在传统的ASP中，如果你不用集成的Windows验证，用户身份验证和授权是很难实现的。例如，确定每个用户身份都经过了验证并不容易。每个ASP页面都需要代码来检验用户身份验证cookie并证明用户身份得到了确定。在ASP.NET中，身份验证和授权比在传统的ASP中要容易多了。在ASP.NET中，有三种形式的身份验证：Windows验证、Passport验证和Forms验证。
Windows验证很简单，用于简单的应用程序。它根据当前域的Active Directory（AD）来验证用户身份。用户组被当作角色来进行基于角色的验证。用户组的角色可能不像应用程序需要的那么细化，所以它们必须存在另一个数据库或自己的AD中；Windows验证不能改变这些角色。
Passport验证是Microsoft的.NET My Services策略的一部分，用来验证Internet程序中的用户。Passport是个单点登录（SSO）服务，允许注册用户用一个单一的用户ID和密码来访问相关的网站。Microsoft Passport服务器负责维护用户身份信息并提供一个验证机制。Passport的wallet功能给用户提供了选项来存储他们的信用卡信息并与网站共享。如果网站需要更多的信息，它们可以在它们自己的数据库中得到那个信息，并将它同Passport用户ID结合起来。这对用户是有好处的，因为她的信息是集中存储的，她不需要访问每个网站时都重复输入信息。对于企业来说，这种验证有不好的地方，因为它们必须相信一个数据库，而它们对这个库却无法控制。到目前为止，Passport验证很难被人们广泛采用而成为一种可行的验证方法。
与Passport验证不同，Forms验证具有灵活性，你可以插入定制的验证代码，并开发公共的安全组件。你可以在服务器端machine.config中配置它，一旦完成配置，组件就自动插入那个服务器上的所有应用程序中了。
研究安全组件
ASP.NET提供了一个很好的方法用HttpModule在请求执行的路径中插入新的功能。开发人员可以创建定制的HttpModule，用来验证内部/外部用户，建立用户角色并创建一个定制的主要对象。关于一个简单的定制HttpModule，你可以下载代码样例（见列表1）。
你也可能想考虑你的安全组件的一些其它的功能。例如，拥有一个安全管理控制台会很好。这样就提供了设施来定义应用程序角色，给角色授权（URLS和操作），并给用户授予角色。当你有一个控制台应用程序时，你可以委派管理责任，包括安全设置。人们改变角色时，对于一个给定的角色来说，应用程序功能就改变了，这时候组件很有用，
你可能想扩展安全模块来查看URL和它的操作代码，并查看用户是否被授权了。应用程序中的每个资源或URL可以有多个操作过程，如查看、创建、更新和删除。如果你可以在操作上（而不是资源上）控制用户的访问，这会很有用。这就使ASP.NET页面可以为相关用户得到操作清单，而不用担心用户拥有什么角色。最后，考虑提供ASP.NET服务器端组件个性化，根据用户能力来实施应用程序菜单。
一旦你得到了适当的安全组件，你就做好准备研究你的数据访问方法了。人们在这方面常犯的错误就是在显示层开发所有的东西，包括你的商业逻辑和数据访问组件。这种开发就导致了很难维护的像意大利面条一样的代码（见资源）。它也使改变数据库的计划或者改变到一个全新的数据库变得很难、很昂贵，因为你必须找到散布在你的应用程序中的所有的单独的数据访问调用指令。用四个层来构建你的企业级的应用程序——显示层、工作流层、商业层和数据访问层——可以使应用程序更容易维护、更具扩展性。
关于这个话题，我将重点讲述数据访问层。应用程序需要将数据访问层同商业对象明显分离开。你不想让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）。
你应该用松散藕合的层来构建应用程序。这样可以提高应用程序的可维护性、可扩展性和重用性。这种方法包含用于每个表的一个Proxy对象和一个Domain对象。Proxy对象包含SQL语句或存储过程调用来得到或保存domain对象。Domain对象包含属性来呈现表的特性。
我们有必要探讨一下关于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
