三层架构到底是个什么玩意?

名词解释:

架构:架构一般是针对整个系统的,并非针对某个单独的问题(单独的问题可以用模式来解决),针对整个系统的”一个蓝图”,对系统的抽象。

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

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

三层:

表现层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三个模块就叫三层了。下面这几个问题:

1、UILayer里面只有少量(或者没有)SQL语句或者存储过程调用,并且这些语句保证不会修改数据?

2、如果把UILayer拿掉,你的项目还能在Interface/API的层次上提供所有功能吗?

3、你的DAL可以移植到其他类似环境的项目吗?

4、三个模块,可以分别运行与不同的服务器吗?

如果不是所有答案都为YES,那么你的项目还不能算是严格意义上的三层程序。三层程序有一些需要约定遵守的规则:

1、最关键的,UI层只能作为一个外壳,不能包含任何BizLogic的处理过程

2、设计时应该从BLL出发,而不是UI出发。BLL层在API上应该实现所有BizLogic,以面向对象的方式

3、不管数据层是一个简单的SqlHelper也好,还是带有Mapping过的Classes也好,应该在一定的抽象程度上做到系统无关

4、不管是用COM+( Enterprise Server ),还是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里,则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。

×

谢谢你请我吃辣条

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

文章目录
  1. 1. 名词解释:
    1. 1.1. 架构:架构一般是针对整个系统的,并非针对某个单独的问题(单独的问题可以用模式来解决),针对整个系统的”一个蓝图”,对系统的抽象。
    2. 1.2. 模式:软件开发中遇到的一些特定问题,前任总结出来特定的经验、解决方法。
    3. 1.3. 框架:架构设计、模式应用的经验积累的具体代码实现,方便以后的复用。
  2. 2. 三层:
    1. 2.1. 表现层UI(User Interface):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
    2. 2.2. 业务逻辑层BLL(Business Logic Layer):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。(备注:又称领域层,常用业务规则、数据访问、合法性校验等等) 。其实,逻辑层就像房屋中介,租房买房跟快捷了,但消耗的钱也跟多了。
    3. 2.3. 数据访问层DAL(Data Access Layer):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。(领域对象:crud)
  3. 3. 优点:
    1. 3.1. 1、开发人员可以只关注整个结构中的其中某一层;
    2. 3.2. 2、可以很容易的用新的实现来替换原有层次的实现;
    3. 3.3. 3、可以降低层与层之间的依赖;
    4. 3.4. 4、有利于标准化;
    5. 3.5. 5、利于各层逻辑的复用;
    6. 3.6. 6、结构更加的明确;
    7. 3.7. 7、在后期维护的时候,极大地降低了维护成本和维护时间。
  4. 4. 缺点:
    1. 4.1. 1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以次获取相应的数据,如今却必须通过中间层来完成。;
    2. 4.2. 2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表现层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。;
    3. 4.3. 3、一定程度上增加了开发的成本。;
  5. 5. 规则
    1. 5.1. 1、UILayer里面只有少量(或者没有)SQL语句或者存储过程调用,并且这些语句保证不会修改数据?
    2. 5.2. 2、如果把UILayer拿掉,你的项目还能在Interface/API的层次上提供所有功能吗?
    3. 5.3. 3、你的DAL可以移植到其他类似环境的项目吗?
    4. 5.4. 4、三个模块,可以分别运行与不同的服务器吗?
    5. 5.5. 1、最关键的,UI层只能作为一个外壳,不能包含任何BizLogic的处理过程
    6. 5.6. 2、设计时应该从BLL出发,而不是UI出发。BLL层在API上应该实现所有BizLogic,以面向对象的方式
    7. 5.7. 3、不管数据层是一个简单的SqlHelper也好,还是带有Mapping过的Classes也好,应该在一定的抽象程度上做到系统无关
    8. 5.8. 4、不管是用COM+( Enterprise Server ),还是Remoting,还是WebService之类的远程对象技术,不管部署的时候是不是真的分别部署到不同的服务器上,最起码在涉及的时候要做这样的考虑,更远的,还得考虑多台服务器通过负载均衡做集群。
  6. 6. 三层与MVC的区别
    1. 6.1. 同样是架构级别的,它们有什么相同点和不同点呢?这篇文章讨论一下它们的异同点。希望能帮助读者理解其中的玄机。
    2. 6.2. 其实它们相同的地方在于他们都有一个表现层。
    3. 6.3. 但是他们不同的地方在于其他的两个层。
    4. 6.4. 首先先解释一下MVC。V即View.是视图的意思。C即Controler.是控制器的意思。而M即Model,是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model,而为什么叫Model。我先不说为什么叫Model,先解释Controler。
    5. 6.5. Controller是控制器的意思,所谓控制器,就是将用户请求转发给模型层,经过处理后把结果返回到界面展现的一个中间层,那么Controler到底管什么工作呢?先不说.先来看下在Java Web中这三个层一般的定义,一般在Java Web里,JSP充当V,Servlet充当C,JavaBean充当M,这里的Servlet管什么工作呢?接受输入,转到Model层去处理,处理结果保存后转发到JSP,然后展现数据。所以它的功能就是控制器的基本功能,它就管转发,在V和M之间转来转去。
    6. 6.6. 再来说说M,即Model,在Java Web里说的是JavaBean,我认识的很多人都把JavaBean误认为是实体类,其实JavaBean有比实体类更丰富的定义,在JavaBean中除了其属性和字段,还可以有行为及其事件,JavaBean可以理解为普通Java对象。Java普通对象,就是符合Java规范的所有对象,这和实体类完全是两回事。所以,我认为在MVC中。业务逻辑和数据访问应该放在Model层,也就是V负责展示数据,Controler除了转发不做业务逻辑。真正的逻辑事务,数据访问,甚至算法都放到Model去。
    7. 6.7. 再说三层架构。三层其实很好理解,界面,业务,数据访问,就这三个,从字面都可以理解出它们的意思。我要说的是它和MVC的区别。在三层架构中没有定义Controler的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。
    8. 6.8. 当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是已实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。
,