三层架构利弊及用法

名词解释

架构：架构一般是针对整个系统的，并非针对某个单独的问题（单独问题可以用模式等来解决）针对整个系统的”一个蓝图”，对系统的抽象。

模式：软件开发中遇到的一些特定问题，前人总结出来特定的经验、解决方法。

框架：架构设计、模式应用的经验积累的具体代码实现，方便以后的复用。

三层

表现层UI（User Interface）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

业务逻辑层BLL（Business Logic Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（备注：又称领域层，常用于业务规则、数据访问、合法性校验）

数据访问层DAL（Data Access Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（领域对象：crud）

（新的：逻辑层就像房屋中介，租房买房更快捷了，但消耗的钱也更多了。）

优点：

1、开发人员可以只关注整个结构中的其中某一层；

2、可以很容易的用新的实现来替换原有层次的实现；

3、可以降低层与层之间的依赖；

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明确

7、在后期维护的时候，极大地降低了维护成本和维护时间

缺点：

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3、增加了开发成本。

规则：

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

三层结构示图

 

三层与MVC的区别

同样是架构级别的，它们有什么相同点和不同点呢？这篇文章讨论一下它们的异同点。希望能帮助读者理解其中的玄机。

其实它们相同的地方在于他们都有一个表现层。

但是他们不同的地方在于其他的两个层。

首先先解释一下MVC。V即View.是视图的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model，而为什么叫Model。我先不说为什么叫Model，先解释Controler。

Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处理后把结果返回到界面展现的一个中间层，那么Controler到底管什么工作呢？先不说.先来看下在Java Web中这三个层一般的定义，一般在Java Web里，JSP充当V，Servlet充当C,JavaBean充当M，这里的Servlet管什么工作呢？接受输入，转到Model层去处理，处理结果保存后转发到JSP，然后展现数据。所以它的功能就是控制器的基本功能，它就管转发，在V和M之间转来转去。

再来说说M，即Model，在Java Web里说的是JavaBean，我认识的很多人都把JavaBean误认为是实体类，其实JavaBean有比实体类更丰富的定义，在JavaBean中除了其属性和字段，还可以有行为及其事件，JavaBean可以理解为普通Java对象。Java普通对象，就是符合Java规范的所有对象，这和实体类完全是两回事。所以，我认为在MVC中。业务逻辑和数据访问应该放在Model层，也就是V负责展示数据，Controler除了转发不做业务逻辑。真正的逻辑事务，数据访问，甚至算法都放到Model去。

再说三层架构。三层其实很好理解，界面，业务，数据访问，就这三个，从字面都可以理解出它们的意思。我要说的是它和MVC的区别。在三层架构中没有定义Controler的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。

当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是已实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。

SqlHelper类

SqlHelper.cs是多年前微软出品的一个使用ADO.Net方法对SQL Server数据库进行操作的封装类。而我们自己手写的SqlHelper类同样是对数据库访问方法的一个封装类库，让我们在访问数据库的时候可以很方便地调用其中封装的方法，省略了很多重复劳动。在声明SqlHelper的时候,我们一般会声明为一个静态类，不使用静态类的话有可能产生一些未知的错误（苏老师说微软说的）。

这个类中我们常用的方法如下：

1. ExecuteNonQuery(): 执行简单的无返回值的查询。
2. ExecuteReader(): 使用DataReader读取数据。（注：少量数据的情况下使用   SqlDataReader的效率高于使用Dataset）
3. ExecuteScalar(): 返回结果集中的第一行第一列，相当于返回单个值。
4. ExcuteDataSet (): 返回Dataset的查询，相当于返回一个数组。

除此之外，我们根据需要以及兴趣也可以再增加一些其他的方法，对其进行修改以及扩展。

三层使用及案例

第一部分：

登陆：对T_Seats表的查询操作

修改密码：对T_Seats表的修改操作

第二部分：

对T_Area表的删除操作（主要知道递归删除算法）

第三部分：

注册（需要注意地方：1、添加操作需要output inserted.cc_AutoId 2、添加之前，还需要验证当前用户是否已经存在，用到了exists()做判断）

第四部分：

建多个类库，实现对T_Seats表和TblPerson表的操作，实现CRUD

 

---

1. Sql语句：select cc_autoId,cc_loginpassword,cc_userName from T_Seats where
2. 编写数据访问层（返回值是一个Model，参数是loginId）
   1. 写model的时候写完全（也就是所有T_Seats中的列名都写成属性的形式）
   2. T_Seats model=null;
   3. return model;
   4. 由于在读取数据库中是数据的时候，里面只能够读取到一条用户名的信息，所以用if（reader.Read()）
3. 编写业务逻辑层
   1. 首先需要查询，就用到了数据访问层中的信息，需要先实例化一个数据访问层“类”
   2. CommonHelper中使用static（静态类）
4. 表现层需要做的事情
   1. 采集数据：界面框中的数据
   2. 然后调用业务逻辑层
   3. 得到业务逻辑层的返回值信息
   4. 由业务逻辑层的信息进行相应的操作（9:26两out参数（why?））
   5. 表现层中写GlobalHelper中的autoId的作用

---

修改密码：（思路）

1.校验两次数据密码是否一致（不需要sql语句）

2.校验旧密码是否正确（根据autoId来判断旧密码是否正确）

 

3.修改密码（如果旧密码正确的话，再开始进行    修改密码    操作）

 

在BLL中的操作

1. 首先判断返回给UI层的结果：用枚举类型来写
2. 得到了返回值类型
3. 编写修改密码的方法，确定参数

---

1. 省市加载到treeview上
2. 三层删除当前节点下的所有节点（1在BLL层先写一个删除方法；2然后使用递归删除方法；3在递归删除过程当中，又调用了加载过程当中的递归加载方法）

---

项目的操作

分多个项目的增删改查

配置文件放在UI层（表现层）

里面的都写成类库类型

model中最好和表中的列一样

多个项目之间需要在”引用“当中添加引用