11.16

三层架构（3-TIerarchitecture）通常意义上的三层架构就是将整个业务应用划分为：界面层（UserInterfacelayer）、业务逻辑层（BusinessLogicLayer）、数据访问层（Dataaccesslayer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
1：数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。

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

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

表示层的内容就是来和用户打交道，通俗讲就是展现给用户的界面，用户的要求都体现在界面上。

三层架构的原理及实现_三层架构怎么用----各层之间的关系

业务逻辑层的功能主要是实现一些具体问题的操作，它是表示层和数据访问层之间沟通的桥梁，主要负责数据的传递和处理。

数据访问层的功能就是对数据库中表的内容的增删改查。

三层的实现将我们的系统的实现过程分门别类，每一层自己做自己的事，互不影响，当我需要其他层的内容时，再去调用。当需要修改时只需改动本层的内容，不会影响到整个系统的代码。

就是传说中的解耦。让那个每一层只关心自己内部的事情，它只知道下层的存在，不知道上层的存在。达到局部改变而不影响全局的目的！

三层结构的程序不是说把项目分成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就足够了，完全没必要作的这么复杂。 而多层结构，是用于解决真正复杂的项目需求的

标签：逻辑,表示层,11.16,BLL,访问,三层,数据
来源： https://www.cnblogs.com/wangyifei111/p/15597615.html