正在阅读：提升开发效率－.NET应用程序开发标准化提升开发效率－.NET应用程序开发标准化

　　研究安全组件

　　ASP.NET提供了一个很好的方法用HttpModule在请求执行的路径中插入新的功能。开发人员可以创建定制的HttpModule，用来验证内部/外部用户，建立用户角色并创建一个定制的主要对象。关于一个简单的定制HttpModule，你可以下载代码样例（见列表1）。

　　你也可能想考虑你的安全组件的一些其它的功能。例如，拥有一个安全管理控制台会很好。这样就提供了设施来定义应用程序角色，给角色授权（URLS和操作），并给用户授予角色。当你有一个控制台应用程序时，你可以委派管理责任，包括安全设置。人们改变角色时，对于一个给定的角色来说，应用程序功能就改变了，这时候组件很有用，

　　你可能想扩展安全模块来查看URL和它的操作代码，并查看用户是否被授权了。应用程序中的每个资源或URL可以有多个操作过程，如查看、创建、更新和删除。如果你可以在操作上（而不是资源上）控制用户的访问，这会很有用。这就使ASP.NET页面可以为相关用户得到操作清单，而不用担心用户拥有什么角色。最后，考虑提供ASP.NET服务器端组件个性化，根据用户能力来实施应用程序菜单。

　　一旦你得到了适当的安全组件，你就做好准备研究你的数据访问方法了。人们在这方面常犯的错误就是在显示层开发所有的东西，包括你的商业逻辑和数据访问组件。这种开发就导致了很难维护的像意大利面条一样的代码（见资源）。它也使改变数据库的计划或者改变到一个全新的数据库变得很难、很昂贵，因为你必须找到散布在你的应用程序中的所有的单独的数据访问调用指令。用四个层来构建你的企业级的应用程序——显示层、工作流层、商业层和数据访问层——可以使应用程序更容易维护、更具扩展性。

　　关于这个话题，我将重点讲述数据访问层。应用程序需要将数据访问层同商业对象明显分离开。你不想让SQL语句散布在从显示层到商业层的所有代码中。这些层不需要知道数据是如何得到的，从哪里得到的。

　　Microsoft包含两个新的对象——Dataset和DataReader——它们作为ADO.NET的一部分来分离各个层。Dataset对象对于一个不连接的应用程序模式是很有用的，而DataReader对象则用于连接的应用程序。然而，这些对象都有一个缺点：当你访问属性的值时，它们或者通过名字或者通过列号来查找。在通过列的名字访问数据的情况下，如果在这些名字中有一个typo，在编译时就不会被检测出来。当列名散布在你的代码中时，就很难在以后改变它们的名字了。如果你通过列号来访问数据，代码更难读，而且你需要知道列在Dataset或DataReader中出现的顺序。