通过为你的企业建立一个公共的应用程序结构框架来提高.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对象包含属性来呈现表的