3、数据访问层（DAL，也可以称为持久层）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务．其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。
简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
规则
三层结构的程序不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了，下面几个问题在你的项目里面：
⒈ UILayer里面只有少量（或者没有）SQL语句或者存储过程调用，并且这些语句保证不会修改数据?
⒉ 如果把UILayer拿掉，你的项目还能在Interface/API的层次上提供所有功能吗?
⒊ 你的DAL可以移植到其他类似环境的项目吗?
⒋ 三个模块，可以分别运行于不同的服务器吗?
如果不是所有答案都为YES，那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：
⒈ 最关键的，UI层只能作为一个外壳，不能包含任何BizLogic的处理过程
⒉ 设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，以面向对象的方式
⒊ 不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关
⒋ 不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群
所以考虑一个项目是不是应该应用三层/多层设计时，先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了，完全没必要作的这么复杂. 而多层结构，是用于解决真正复杂的项目需求的。
优点
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
缺点
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
与MVC的区别
MVC（模型Model-视图View-控制器Controller）是一种设计模式，可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层（视图），但是他们不同的地方在于其他的两个层。
- （控制器Controller）- 负责转发请求，对请求进行处理。起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。
- （视图View） - 界面设计人员进行图形界面设计。能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。
- （模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制
器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的
视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
优点
1、多个视图能共享一个模型。在MVC设计模式中，模型响应用户请求并返回响应数据，视图负责格式化数据并把它们呈现给用户，业务逻辑和表示层分离，同一个模型可以被不同的视图重用，所以大大提高了代码的可重用性。
2、控制器是自包含（self-contained）指高独立内聚的对象，与模型和视图保持相对独立，所以可以方便的改变应用程序的数据层和业务规则。
3、由于MVC模式的三个模块相互独立，改变其中一个不会影响其他两个，所以依据这种设计思想能构造良好的少互扰性的构件。
4、控制器提高了应用程序的灵活性和可配置性。控制器可以用来连接不同的模型和视图去完成用户的需求，也可以构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择适当的模型进行处理，然后选择适当的的视图将处理结果显示给用户。
评价及适用范围
MVC模式的缺点是由于它没有明确的定义，所以完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需
要花费一些时间去思考。开发一个MVC模式架构的工程，将不得不花费相当可观的时间去考虑如何将MVC模式运用到应用程序中，同时由于模型和视图要严格的
分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于MVC模式将一个应用程序分成了三个部件，所以这意味着
同一个工程将包含比以前更多的文件。
过去MVC模式并不适合小型甚至中等规模的应用程序，这样会带来额外的工作量，增加应用的复杂性。但现在多数软件设计框架，能直接快速提供MVC骨
架，供中小型应用程序开发，此问题不再存在。对于开发存在大量用户界面，并且逻辑复杂的大型应用程序，MVC将会使软件在健壮性、代码重用和结构方面上一
个新的台阶。尽管在最初构建MVC模式框架时会花费一定的工作量，但从长远的角度来看，它会大大提高后期软件开发的效率。
实现
MFC
微软所推出的MFC Document/View架构是早期对于MVC模式的实现，MFC将程序分成CView以及CDocument两大类型，其中的Document对应MVC中的Model，View相当于MVC中的View＋Controller，再加上CWinApp类型，合成三大项。但是基本上MFC是一个失败的MVC模式作品。
由于MFC之下的Document/View定义过于模糊，未将Controller（MessageMap）部份取出，因此Controller可以置入View或Document，但不管置入哪一方面，都会与View或Document绑死，没有弹性。
JAVA
JAVA 平台企业版 (J2EE)
和其他的各种框架不一样，J2EE为模型对象（Model Objects）定义了一个规范。
- 视图(View)
- 在J2EE应用程序中，视图（View）可能由Java Server Page(JSP)承担。生成视图的代码则可能是一个Servlet的一部分，特别是在客户端服务端交互的时候。
- 控制器（Controller）
- J2EE应用中，控制器可能是一个servlet，现在一般用Struts2/Spring Framework实现。
- 模型（Model）
- 模型则是由一个实体Bean来实现。
Java开发Web Application有几种符合MVC设计模式的开发方式。
1:Jsp+Servlet+JavaBean(EJB)
2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)
3:TDK(Turbine，Velocity...)
4:Xsp
5:Jsp+Struts+JavaBean(EJB)
