三层架构：html
一般意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最多见，也是最重要的一种结构。微软推荐的分层式结构通常分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。数据库
顾名思义，三层架构分为三层，分别是“数据访问层”、“业务逻辑层”、“表示层”。
数据访问层：数据访问层在做业过程当中访问数据系统中的文件，实现对数据库中数据的读取保存操做。
表示层：主要功能是显示数据和接受传输用户的数据，能够在为网站的系统运行提供交互式操做界面，表示层的应用方式比较常见，例如Windows窗体和Web页面。
业务逻辑层：将用户的输入信息进行甄别处理，分别保存。创建新的数据存储方式，在存储过程当中对数据进行读取，将“商业逻辑”描述代码进行包含。
三层架构软件系统为用户的数据传输、提取、储存创造了便利条件。在应用数据时，信息划分架构开发项目，对各层次之间的工做职责进行清晰规划，这样就下降了网站系统的维护风险。
原理：
3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。
所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，
不是指物理上的三层，也不是简单地放置三台机器就是三层体系结构，固然也不只仅有B/S应用才是三层体系结构，
三层是指逻辑上的三层，即把这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工做放到了中间层进行处理。一般状况下，客户端不直接与数据库进行交互，而是经过COM/DCOM通信与中间层创建链接，再经由中间层与数据库进行交互。
三层架构中主要功能与业务逻辑通常要在业务逻辑层进行信息处理和实现，其中三层体系架构中的客户端和数据库要预设中间层，成为组建层。三层架构中的三层具备必定的逻辑性，便是将三层设置到同一个计算机系统中，把业务协议、合法校验以及数据访问等程序归置到中间层进行信息处理，通常客户端没法和数据库进行数据传输，主要是利用COM/DCOM通信和中间层构建衔接通道，实现中间层与数据库的数据传输，进而实现客户端与是数据库的交互。
结构：
表示层
表示层又称表现层UI，位于三层构架的最上层，与用户直接接触，主要是B/S信息系统中的Web浏览页面。做为Web浏览页面，表示层的主要功能是实现系统数据的传入与输出，在此过程当中不须要借助逻辑判断操做就能够将数据传送到BLL系统中进行数据处理，处理后会将处理结果反馈到表示层中。换句话说，表示层就是实现用户界面功能，将用户的需求传达和反馈，并用BLL或者是Models进行调试，保证用户体验。
业务逻辑层
业务逻辑层BLL的功能是对具体问题进行逻辑判断与执行操做，接收到表现层UI的用户指令后，会链接数据访问层DAL，访问层在三层构架中位于表示层与数据层中间位置，同时也是表示层与数据层的桥梁，实现三层之间的数据链接和指令传达，能够对接收数据进行逻辑处理，实现数据的修改、获取、删除等功能，并将处理结果反馈到表示层UI中，实现软件功能。
数据访问层
数据访问层DAL是数据库的主要操控系统，实现数据的增长、删除、修改、查询等操做，并将操做结果反馈到业务逻辑层BLL。在实际运行的过程当中，数据访问层没有逻辑判断能力，为了实现代码编写的严谨性，提升代码阅读程度，通常软件开发人员会在该层中编写DataAccessCommon，保证数据访问层DAL数据处理功能。
简单的说法就是实现对数据表的Select（查询），Insert（插入），Update（更新），Delete（删除）等操做。若是要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
数据访问层，简单的说，就是经过DAL对数据库进行的SQL语句等操做。
数据库访问层的主要职责是：读取数据和传递数据。
各层的做用
一、数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操做层，而不是指原始数据，也就是说，是对数据库的操做，而不是数据，具体为业务逻辑层或表示层提供数据服务。
二、业务逻辑层：主要是针对具体的问题的操做，也能够理解成对数据层的操做，对数据业务逻辑处理，若是说数据层是积木，那逻辑层就是对这些积木的搭建。
三、界面层：主要表示WEB方式，也能够表示成WINFORM方式，WEB方式也能够表现成：aspx，若是逻辑层至关强大和完善，不管表现层如何定义和更改，逻辑层都能完善地提供服务
举个例子
服务员：只管接待客人；架构
厨师：只管作客人点的菜；app
采购员：只管按客人点菜的要求采购食材；网站
他们各负其职，服务员不用了解厨师如何作菜，不用了解采购员如何采购食材；spa
厨师不用知道服务员接待了哪位客人，不用知道采购员如何采购食材；架构设计
一样，采购员不用知道服务员接待了哪位客人，不用知道厨师如何作菜。设计
那他们三者是如何联系的？3d
顾客直接和服务员打交道，顾客和服务员（UI层）说：我要一个炒茄子，而服务员不负责炒茄子，她就把请求往上递交，传递给厨师（BLL层），厨师须要茄子，就把请求往上递交，传递给采购员（DAL层），采购员从仓库里取来茄子传回给厨师，厨师响应cookEggplant()方法，作好炒茄子后，又传回给服务员，服务员把茄子呈现给顾客。调试
这样就完成了一个完整的操做。
在此过程当中，茄子做为参数在三层中传递，若是顾客点炒鸡蛋，则鸡蛋做为参数（这是变量作参数）。若是，用户增长需求，咱们还得在方法中添加参数，一个方法添加一个，一个方法设计到三层；况且实际中并不止设计到一个方法的更改。因此，为了解决这个问题，咱们能够把茄子、鸡蛋、面条做为属性定义到顾客实体中，一旦顾客增长了炒鸡蛋需求，直接把鸡蛋属性拿出来用便可，不用再去考虑去每层的方法中添加参数了，更不用考虑参数的匹配问题。
这样讲，你们应该能够明白吧
这只是一部分的内容，另外一部分请看个人另外一篇博客
（三层构架二）