为什么系统要分层如何知晓公司系统中采用的是什么分层架构( 二 ) _为什么软件要分系统

文章插图
表现层（UI），通俗讲就是展现给用户的界面，对应项目中的Web层包含Servlet和Controller等。
业务逻辑层（BLL）：也称作领域层，负责系统业务逻辑的处理，对应项目中Service和ServiceImpl等。
数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等，对应项目中的Dao 。
在提出该分层架构的时代，多数系统往往较为简单，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是Client-Server架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。
在开源技术框架中，表现层实现的代表作品是Struts1/2、Spring MVC ，业务层实现的代表作品是Spring，持久层实现的代表作品是Hibernate和Mybatis 。
MVCMVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
标准的MVC交互模型如下图：

文章插图
View：视图，为用户提供使用界面，与用户直接进行交互。
Model：模型，承载数据，对用户提交请求进行计算的模块。分为两类，一类称为数据承载Bean ，一类称为业务处理Bean 。数据承载Bean是指实体类，专门承载业务数据的，如Student、User等。而业务处理Bean则是指Service或Dao对象，专门用于处理用户提交请求的。
Controller：控制器，用于将用户请求转发给相应的Model进行处理，并处理Model的计算结果向用户提供响应。
从图中可以看到，标准的MVC中模型能主动推数据给视图进行更新（观察者设计模式，在模型上注册视图，当模型更新时自动更新视图），但在Web开发中模型是无法主动推给视图（无法主动更新用户界面），因为在Web开发是请求-响应模型。
Web MVC标准架构，如下图所示：

文章插图
在Web MVC模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。MVC用于将web（UI）层进行职责解耦。
三层架构和MVC的区别与联系MVC严格说是三层架构中的UI层，也就是说， MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话，而C层直接与三层中的BLL进行对话。
三层架构和MVC可以共存。三层架构是基于业务逻辑来分的，而MVC是基于页面来分的。MVC是表现模式（Presentation Pattern），三层架构是典型的架构模式（Architecture Pattern）。
三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。
阿里四层架构三层架构实现比较简单，很多朋友可能觉得项目分层就应该如此，结果就是往往会出现一大堆的业务逻辑都堆砌在Service层中。而在《阿里巴巴 Java 开发手册》中将原来的三层架构进一步细化，添加了Manager通用业务处理层。