三层架构：表示层——业务逻辑层——数据访问层

1. 什么是三层架构

所谓的三层开发就是将系统的整个业务应用划分为 表示层,业务逻辑层,数据访问层，这样有利于系统的开发、维护、部署和扩展。分层是为了实现 “高内聚，低耦合”，采用 “分而治之” 的思想，把问题划分开来各个解决，易于控制、易于延展、易于分配资源。进行软件开发设计，一定要懂得

分而治之

分而治之

分而治之

• 表示层：负责直接跟用户进行交互，一般也就是指系统的界面，用于数据录入，数据显示等。意味着只做与外观显示相关的工作，不属于他的工作不用做。
• 业务逻辑层：用于做一些有效的验证工作，以更好地保证程序运行的健壮性。如完成数据添加、修改和查询等；不允许指定的文本框中输入空字符串，数据格式是否正确及数据类型验证；用户的权限合法性判断等。通过以上诸多判断以决定是否将操作继续向后传递，尽量保证程序的正常运行。
• 数据访问层：顾名思义，就是专门跟数据库进行交互，执行数据的添加、删除、修改和显示等。需要强调的是，所有的数据对象只在这一层被引用，除数据层之外的任何地方都不应该出现这样的引用。

ASP.NET可以使用.NET平台快速方便地部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#、VB、C++和J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名空间可以方便的使用自己定义的组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件或封装类来实现，这样就很方便的实现了三层架构。

2. 为什么使用三层架构

对于一个简单的应用程序来说，代码量不是很多的情况下，一层结构或二层结构开发完全够用，没有必要将其复杂化，如果对一个复杂的大型系统，设计为一层结构或二层结构开发，那么这样的设计存在很严重缺陷。下面会具体介绍，分层开发其实是为大型系统服务的。

在开发过程中，初级程序人员出现相似的功能经常复制代码，那么同样的代码为什么要写那么多次？不但使程序变得冗长，更不利于维护，一个小小的修改或许会涉及很多页面，经常导致异常的产生使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的道路。

意识到这样的问题，初级程序人员开始将程序中一些公用的处理程序写成公共方法，封装在类中，供其他程序调用。例如写一个数据操作类，对数据操作进行合理封装，在数据库操作过程中，只要类中的相应方法（数据添加、修改、查询等）可以完成特定的数据操作，这就是数据访问层，不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。读者现在似乎找到了面向对象的感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便，也实现了代码的重用性。

下面举两个案例，解释一下为什么要使用三层架构。

案例一：

数据库系统软件由于数据量的不断增加，数据库由Access变成了SQLServer数据库，这样原来的数据访问层失效了，数据操作对象发生了变化，并且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，SQLServer和Access支持的数据类型也不一致，在显示数据时进行的数据转换也要进行修改，这是其中一种情况。

案例二：

由于特殊情况需要，把Web形式的项目改造成Windows应用，此时需要做多少修改呢？如果在Aspx.cs中占据了大量代码，或者还有部分代码存在于Aspx中，那么整个系统是否需要重新来开发呢？

在上面的案例中是否体会到了没有分层开发模式的缺陷呢？是否碰到过这样的情况呢？这都是由设计不合理造成的，多层开发架构的出现可以很好地解决该问题，通过程序架构进行合理的分层，将极大地提高程序的通用性。

3. 使用三层架构开发的优点

使用三层架构开发有以下优点：

• 从开发角度和应用角度来看，三层架构比二层架构或单层架构都有更大的优势。三层架构适合团队开发，每人可以有不同的分工，协同工作使效率倍增。开发二层或单层应用程序时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用程序时，则可以结合多方面的人才，只需少数人对系统全面了解即可，从一定程度降低了开发的难度。

• 三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以在多个计算机上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破解不了的密码。

• 三层架构的最大优点是它的安全性。用户只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。

4. 三层架构的种类

目前，团队开发人员在开发项目时，大多都使用分层开发架构设计，最常见的就是三层架构，目的在于使各个层之间只能够被它相邻的层产生影响，但是这个限制常常在使用多层开发的时候被违反，这对系统的开发是有害的。三层架构按驱动模式可划分三种：数据层驱动模式、陈述层驱动模式和隔离驱动模式，其中隔离驱动模式开发最为重要。下面通过三种模式的对比，介绍隔离驱动模式的重要性。

• 数据层驱动模式

所谓的数据层驱动模式，就是先设计数据层，陈述层围绕数据层展开，一旦完成了数据层和陈述层，业务层就围绕数据层展开。因为陈述层是围绕数据层展开的，这将会使陈述层中的约束不准确，并且限制了业务层的变更。由于业务层受到限制，一些简单变化可以通过SQL查询和存储过程来实现。

这种模式非常的普遍，它和传统的客户服务端开发相似，并且是围绕已经存在的数据库设计的。由于陈述层是围绕数据层设计的，它常常是凭直觉模仿数据层的实际结构。

常常存在一种额外的反馈循环在陈述层到数据之间，当在设计陈述层不容易实现的时候常常会去修改数据层，也就形成了这种反馈循环。开发者请求修改数据库方便陈述层的开发，但是对数据层的设计却是有害的。这种改变是人为的而没考虑到其他需求的限制。这种修改经常会违反至少损害数据的特有规则，导致不必要的数据冗余和数据的非标准化。

• 陈述层驱动模式

陈述层驱动模式是数据层围绕陈述层展开的。业务层的完成一般是通过简单的SQL查询和很少的变化或者隔离。由于数据库的设计是为了陈述层的方便，并非从数据层设计方面考虑，所以数据库的设计在性能上通常很低。

• 隔离驱动模式

用隔离驱动模式设计，陈述层和数据层被独立的开发，常常是平行开发。这两层在设计时没有任何的相互干扰，所以不会存在人为的约束和有害的设计元素。当两层都设计完成后，再设计业务层。业务层的责任就是在没有对数据层和陈述层的需求变化的基础上完成所有的转换。

因为现在陈述层和数据层是完全独立的，当业务层需求改变的时候，陈述层和数据层都可以做相应的修改而不影响对方。改变两个在物理上不相邻的层不会直接对其他层产生影响或发生冲突。这就允许数据层结构的调整或者陈述层根据用户的需求做相应的变化，而不需要系统做大的调整或者修改。下表将对这3种驱动模式进行对比。

	数据层驱动模式	陈述层驱动模式	隔离驱动模式
数据库	1. 很容易设计 2.产生负面影响 3.很难改变数据层，因为它和陈述层紧密绑定	1.数据库设计很糟 2.严重的不规范化设计 3.其他系统不易使用 4.很难改变数据层，由于它跟陈述层紧密绑定	1.优化设计 2.集中设计数据库，陈述层对它影响很小
业务需求	常常不能适应业务需求变化	常常适应业务需求变化	适应需求变化
用户界面	是围绕数据层而不是围绕用户，不易修改	适合用户扩展界面	适合用户扩展界面
扩展性	通常可扩张，但是常常在用户界面需要比较多的重写以满足数据库的结构，同时数据库可能需要存储一些冗余的字段	完整性的扩张很难，常常只有通过“剪切，粘贴”函数来实现	很容易扩展

综上所述，很容易看出隔离驱动模式的优点，隔离驱动模式设计可以极大地提高程序的扩展性。

---