.net网络应用程序三层架构.docVIP

.net网络应用程序三层架构 　　摘 要： 了解网络应用程序基础架构是每一个软件设计者的首要任务，如若对基础架构没有一个清晰的认识，便不会有正确的网络应用程序开发。在网络应用程序基础架构中三层模型（表示层，业务逻辑层和数据访问层）是最基础的架构模型，其他的架构模型都是从这个三层模型中演化出来或者是摘取其中部分环节而成的，为此网络应用程序的三层架构是最基本的也是最应该掌握的。 　　关键词： 表示层；业务逻辑层；数据访问层；B/S；C/S 　　中图分类号：TP311.52 文献标识码：A 文章编号：1671－7597（2012）0310185－01 　　 　　在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构，微软推荐的分层式结构一般分为三层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，三层体系是指逻辑上的三层，即使将这三个层放置到一台机器上。在三层架构基本模型中，运算被分别分布在客户端和服务器端中；客户端是数据呈现运算，被称为表示层（PL）；服务器端则容纳着数据资源，被称为数据访问层（DAL）；在这两者之间是中间层，也被称为业务逻辑层（BLL），或者被称为中间件。类是三层模型中最重要的组成部分，它允许将业务逻辑功能封装在可被许多不同应用程序重复使用的扩展名为.dll的类中。 　　表示层位于最外层（最上层），离用户最近，是一个可维护、可扩展的用户界面层，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。 　　业务逻辑层无疑是系统架构中体现核心价值的部分，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用，提供所有与数据库的操作，包括从数据库返回数据集，向数据库更新数据以及承担部分数据验证功能。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“??屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。 　　数据访问层就是用于专门跟数据库进行交互，对数据进行添加，删除，修改，显示等基本操作。需要强调的是所有的数据对象只在这一层被引用，如System. Data，SqlClient等，除数据访问层之外的任何地方都不应该出现这样的应用。如果要加入ORM（对象关系映射）的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。 　　从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度上降低了开发的难度。三层架构模型能够比较准确地模拟现实业务活动中出现的各项行为和过程，同时开发人员可以只关注整个结构中的某一层，可以很容易的用新的实现来替换原有层次的实现，降低层与层之间的依赖，有利于各层逻辑的复用和标准化，扩展性强，安全性能高，客户端只能通过业务逻辑层来访问数据层，减少了程序的入口点，屏蔽了很多危险的系统功能，项目结构清晰，分工明确，利于程序后期的维护和升级。但是，三层架构模型降低了系统的性能，若不采用分层式结构可以直接访问数据库获取数据，而在分层结构中必须通过中间件来完成；增加了代码量，如若在表示层中增加功能，为了符合分层式结构，在相应的业务逻辑层和数据访问层中都增加相应的代码，增大了工作量。 　　在过去网络应用系统开发中C/S（客户机/服务器，Client/Server的缩写）体系架构得到了广泛的应用，从三层架构模型中来看业务逻辑位于客户一端，客户端发出访问数据资源的请求，服务器端将数据返回客户端。并且，当数据资源到达客户端时，客户机仍会对数据进行处理，并且呈现出来，响应速度较快。但是C/S结构存在着很多体系上的问题，一个最关键的问题就是分发客户端应用程序。这是因为在C/S体系结构下，全部的业务逻辑由一个位于客户机上的应用程序来完成，一旦需求有所发生变化，客户端和服务器端的应用程序就要进行修改，服务器端应用程序的修改还是可以控制的，但是客户端应用程序的修改却很麻烦，必须重新分发给所有的用户端，工作量相当大，这是几乎不可能实现的，特别是在某些业务逻辑不断变化的情况下，给应用程序的维护和升级带来了极大的不便。 　　B/S（浏览器/服务器，Browser/Ser