想了解一些关于软件设计中三层结构相关的知识,于是乎在网上看了一些文章,摘抄了如下内容,以作参阅:

在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层,如图所示:
软件体系架构中的三层结构_休闲

  数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问。简单的说法就是实现对数据表的 Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体 的持久化。在PetShop的数据访问层中,并没有使用ORM,从而导致了代码量的增加,可以看作是整个设计实现中的一大败笔。

  业务逻辑层:是整个系统的核心,它与这个系统的业务(领域)有关。以PetShop为例,业务逻辑层的相关设计,均和网上宠物店特有的逻辑相关,例如查询宠物,下订单,添加宠物到购物车等等。如果涉及到数据库的访问,则调用数据访问层。

  表示层:是系统的UI部分,负责使用者与整个系统的交互。在这一层中,理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码,仅与界面元素有关。在PetShop中,是利用ASP.Net来设计的,因此包含了许多Web控件和相关逻辑。

  分层式结构究竟其优势何在?Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案:
  1、开发人员可以只关注整个结构中的其中某一层;
  2、可以很容易的用新的实现来替换原有层次的实现;
  3、可以降低层与层之间的依赖;
  4、有利于标准化;
  5、利于各层逻辑的复用。

  概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。
一 个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如UI人员只 需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确 认,开发进度就可以迅速的提高。

  松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依 赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优 势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。

  进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。

  “金无足赤,人无完人”,分层式结构也不可避免具有一些缺陷:
  1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
  2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

-------------------------------------------------
转载:http://community.csdn.net/Expert/topic/3699/3699706.xml?temp=.9721033  
  将系统分层是简化系统的好方法,而且已经得到了很好的证实,如OSI(Open   System   Interconnection)七层参考模型,就是一种通信协议的七层抽象参考模型。其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层 次上相互通信。这七层是:物理层、数据链路层、网络层、传输层、会话层、表示层和应用层等。分层的思路是将系统按功能职责进行划分,将同一类职责的功能抽 象为一层。下面以一个信息系统的设计来说明如何进行分层结构设计。  
   
  其中包含以下三层结构。  
  (1)   表示层。  
  (2)   业务层。  
  (3)   数据层。  
   
  与传统的两层结构相比,它最大的特征是将业务层独立了出来,从而提高了业务层的可复用性。在两层结构中,用户界面和业务处理流程放在一起,因此无法直接复 用业务处理的相关功能,也无法将业务处理功能进行灵活的部署。在三层结构中,表示层只处理用户界面相关的功能,业务层专心处理业务流程,可以对业务层进行 灵活的部署,开发时也便于业务处理的开发和用户界面的开发同时进行。  
   
  OSI中要求高层只能调用它的下一层提供的接口,我们设计接口时也应尽量遵守这样的约束。  
   
  数据层在业务层中是可见的,业务层在表示层中是可见的,反之则不可见。为什么在业务层中不能直接访问表示层呢?因为业务层要相对独立,它不能依赖于任何表 示层,以至于一个业务层可以对应多个表示层。业务层可以间接与表示层通信,这种通信方式根据实际需要来确定。  
   
  针对每一层可以设计一个或多个模块,每个模块完成相对独立的功能。  
   
  如表示层中用户界面模块的功能如下。  
  (1)   与用户的交互,接收用户的各种输入以及输出各种提示信息或处理结果。  
  (2)   对于输入的数据进行数据校验,过滤非法数据。  
  (3)   向业务层发送处理请求。  
  业务层中业务处理模块的功能如下。  
  (1)   实现各种业务处理逻辑或处理算法。  
  (2)   验证请求者的权限。  
  (3)   向数据层发送数据操作的请求。  
  (4)   向用户层返回处理结果。  
  数据层中数据访问模块的功能如下。  
  (1)   实现数据的读取与存储操作。  
  (2)   实现事务处理。
---------------------------------------------------
http://topic.csdn.net/t/20060910/13/5011544.html
---------------------------------------------------
三层结构解释

所谓三层体系结构,是在客户端与数据库之间加入了一个中间层,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交换.

理解ASP.NET中的三层结构

我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级.

三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL)

1:数据数据访问层:主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务.

2:业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。

3:表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地
提供服务。

具体的区分方法

1:数据数据访问层:主要看你的数据层里面有没有包含逻辑处理,实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。
2:业务逻辑层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。
3:表示层:主要对用户的请求接受,以及数据的返回,为客户端提供应用程序的访问。