软件开发的三层架构与mvc的区别,mvc开发模式架构图

原文链接：https://mp.weixin.qq.com/s/YzNC2IcS2wHtMrdighB9_w

原作者：程序新视界

只要从事软件开发的工作，系统架构是必备知识。有朋友说可能会说，我只是一个搬砖的，怎么会接触到架构知识呢？其实，除了架构的设计者（也就是架构师），作为普通的开发者也是在时刻践行着系统架构的理论。毕竟，再好的架构，都需要码农去实施。只不过当你没有系统了解软件架构时，可能感知不到而已。

本篇文章就带大家系统的了解一下软件架构的分层，学习完毕，你就会明白，为什么系统要分层。同时，也能准确地看清楚目前自己系统中采用的是什么样的分层架构。

首先我们来思考一个问题，如果一个系统不采用分层架构可不可以？这个问题就好像在问，代码中不使用设计模式行不行？答案当然是可以的。但不采用架构分层，会带来极大的未知风险，或者说代码极具熵增的特性。

作为一个初创软件，可能没有什么业务逻辑，没有什么用户量，而软件最主要的目标就是快速上线，实践商业模式。此时，可以不考虑分层。但随着业务逻辑的复杂，业务板块的增多，彼此之间就会出现错综复杂的依赖关系，随之就会产生的逻辑不清晰、可读性差，维护困难，改动一处动全身等问题。

分层架构是将软件模块按照水平切分的方式分成多个层，一个系统由多层组成，每层由多个模块组成。同时，每层有自己独立的职责，多个层次协同提供完整的功能。比如，我们经常提到的MVC架构，就是一种非常典型非常基础的分层方式。

分层设计的本质其实就是将复杂问题简单化，基于单一职责原则让每层代码各司其职，基于“高内聚，低耦合”的设计思想实现相关层对象之间的交互。从而，提升代码的可维护性和可扩展性。

系统架构分层之后，往往需要达到以下目标：

• 高内聚：分层设计可以简化系统设计，让不同层专注做某一模块的事；
• 低耦合：层与层之间通过接口或API来交互，依赖方不用知道被依赖方的细节；
• 复用：分层之后可以做到代码或功能的复用；
• 扩展性：分层架构可以让代码更容易横向扩展

在计算机领域现有最典型的分层架构设计就是OSI参考模型和TCP/IP参考模型了。关于这个模型，我们在《一篇文章，只用看三遍，终生不忘网络分层! 》一文中已经详细介绍了。下面直接看一下相关的模型图：

对于上述的三种分层模式，试想一下，如果没有分层，当一个业务或协议需要改变时，我们只能针对整个系统做修改或扩展。而分层之后，便可以很方便地把不同功能的模块抽离出来，修改对应的模块即可。而且不同层还可以被复用，只要确保按照这个层的协议来处理就可以了。

以Java软件应用为例，整个软件系统也可进行分层，比如分为部署的硬件环境、操作系统、所需的中间件、承载业务的应用程序以及软件接入层。可通过下图进行整体了解：

对于上述分层也产生了对应在职位，比如运维工程师、中间件工程师、产品经理、开发工程师、测试工程师等工种。而我们在实践过程中，接触最多，使用最多的分层要属应用软件层了，其次是中间件层。

下面我们就来看看针对应用软件层通常有哪些分层方式。

三层架构(3-tier application) ，通常就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

表现层（UI），通俗讲就是展现给用户的界面，对应项目中的Web层包含Servlet和Controller等。

业务逻辑层（BLL）：也称作领域层，负责系统业务逻辑的处理，对应项目中Service和ServiceImpl等。

数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等，对应项目中的Dao。

在提出该分层架构的时代，多数系统往往较为简单，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是Client-Server架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。

在开源技术框架中，表现层实现的代表作品是Struts1/2、Spring MVC，业务层实现的代表作品是Spring，持久层实现的代表作品是Hibernate和Mybatis。

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

标准的MVC交互模型如下图：