MVC设计模式和三层结构（适合初学者）

最新推荐文章于 2021-12-11 11:13:29 发布

小咸白鱼

最新推荐文章于 2021-12-11 11:13:29 发布

阅读量8.6k

点赞数 101

文章标签： MVC设计模式三层结构

本文链接：https://blog.csdn.net/weixin_41896463/article/details/89892612

版权

转载请表明原创：https://blog.csdn.net/weixin_41896463/article/details/89892612

题外话：

我们经常把MVC模式和三层架构联系在一起，一旦让你谈谈MVC设计模式，不可避免的总是会说到三层架构，这对于一些高手和大佬来说并没有什么问题，但是对于一些新手，想要学习MVC设计模式的小白来说，有时候就不太友好了。大多人（包括我）刚开始学的时候，大部分都是看大佬们的博客学习，但是正是如此，被大佬们的博客搞得头晕，很容易将MVC设计模式和三层架构搞混，或者以为是同一个东西，然后就引发出一系列奇奇怪怪的问题在那里绕呀饶，浪费时间在不必要的地方，还心累。

比如：不是说三层吗，怎么就冒出了Model层，View层，Controller层、业务逻辑层、sevice层、dao层……这么多层？哪个层又包括了哪层，javabean和Module是同一种吗？servlet层呢，怎么没有？三层？MVC？具体实现类？……这么一大堆莫名其妙的问题。（都是泪啊……）

当然着并不是说大佬们的不好，技术厉害的人，自然会把一些小白需要学习区分的地方看成是基础，自然不需要做太多的说明（比如让你去教小孩子1+1=2，还是很难的：“这是基础啊，怎么教？记不就行了？”）。

这里我学习之后整理了这篇博客，希望能够对小白们友好一点，对MVC和三层架构有一个更全面的认识。当然我也是小白，所以我有说错的地方希望大佬们能够指出！非常感谢！

当然这篇博客并没有从什么是MVC及其优点开始讲，所以只适合对MVC和javaweb有一定了解的人。

MVC设计模式和三层架构的关系

MVC并不等同于三层架构，两者有着本质的区别，但是也有着密切的联系（不然也不会将两者放在一起了）

区别：

从功能上看：
- 三层架构是一个分层式的软件体系架构设计，适用于所有的项目。
- MVC模式是为了让前端和业务逻辑代码和数据分开，只使用在web项目中。
从目的上看：
- 三层架构的目的是解耦。
- MVC设计模式目的是为了web项目中各类职责的统一规范化（也是解耦）。
- 但是三层架构侧重的是项目整体的解耦，而MVC侧重的是前端页面和业务逻辑处理的一个解耦。
从层次上看：
- 三层架构是框架层面上的。
- 而MVC设计模式是设计模式层面上的。
- 一个软件肯定要先确定好框架，之后才有下一步的设计模式。
- 所以：三层架构明显是要高于MVC设计模式的。

补充：MVC设计模式和23种设计模式的关系：

他们是同一个层面上的，都是为了规范化代码，MVC模式是23种模式中几种模式的变形和整合。从这里也可以看出MVC

模式层次低于三层架构

联系：

两者都用到了分层和解耦的思想
通常的MVC都是在应用三层架构的基础上的，是基于三层架构设计的

（一）三层架构

哪三层

表现层(UI): 与用户交互的界面。可以用于接收用户输入的数据和显示处理后用户需要的数据。（和MVC的View层很像对吧，先别乱，下面会有图说明联系）
业务逻辑层(BLL): 是UI和DAL的桥梁，实现业务逻辑处理。
数据访问层(DAL): 关联着数据库。实现对数据的增删改查。

这里就有人会有疑问了：怎么实现数据的交互呢？着就需要另外一层：实体层(Entity)。(和MVC的Module层也很像吧？但是这个就很不一样，还是看最后的图）

怎么又蹦出另外一个层来了？不是说三层吗？其实三层只是主要的层次而已，还可以是多层的，当然经典的三层就是上面这个，既然说是三层就记三层吧，但是实体层也是必不可少的。

三层架构的分层具有上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系

（二）MVC模式

也是“三层”

Model模型：负责数据库操作，以及业务逻辑的实现，是MVC的主体（很明显和三层架构的实体层不一样，倒是像BLL和DAL的合体）
View视图：用户与系统之间的交互界面。
Controller控制器：根据用户的输入，控制用户界面数据显示和更新model对象状态。起到控制整个业务流程的作用，实现View层跟Model层的协同工作

（三）具体实现

这个或许才是困扰到大多人的关键吧。这个是我们在实现MVC/三层架构的时候，将其细化后分成各个职责明确的包（包含功能类型相同的类）。一般为下面几种：

(这里的几个包有种将MVC和三层打乱结合的感觉，但是都满足分层和解耦的要求)

(此外包名的定义也并不是唯一的，比如module也可以换成entity，主要是功能要正确，但是也不能随意乱改成以意义不明的名字，规范化才是正道！）

view ---------(三层中的UI、MVC中的View)
- 用户界面（比如jsp），和servlet联系紧密，两者一般都是一起开发的
module --------（注：这里的module并不是MVC中的 M，而是三层中的Entity）
- 其实就是javabean，数据表中各字段作为其属性，一一对应，没有业务逻辑处理，增加get、set方法，下面所有包中的类都需要有具体的对象类，实现数据的更新和交换。
service --------(三层中的BLL）
- 负责业务模块的逻辑应用设计，是业务层。业务层不能含有实际对象（即module对象）。封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性，系统化项目。
- 调用dao层中已定义的接口的方法，同时也可以调用其他功能（utils中的方法）
- 被servlet调用
servlet ----------(MVC中的Controller)
- 具体的业务模块流程的控制。联系view和service，根据view需要的操作选择调用service接口中已定义的业务逻辑处理。
dao ------------(三层中的DAL)
- 主要做数据的持久化（说的很高大上，通俗的说就是把数据存放到数据库中保存，持久利用）。和数据库联系，进行数据库的一系列操作。
- 被service调用。
utils ----------(不属于MVC或三层，只是为了简化代码和统一管理建立的工具类)
- 存放一些常用的功能代码（比如数据库连接和断开、判空等等）或者特殊的功能代码，可供sercive、dao等调用

从上面可以看到，项目主体还是以三层结构为主（毕竟是框架），而MVC只是一种实现该框架的设计模式。

service、servlet、dao层一般都是先设计出接口，再设计出其实现类！

简单的系统中，service并不能看出有多大的优点，反而还有点累赘（相信刚学的小白，都是在service里new一个dao类对象然后调用，就没有了，感觉还不如直接调用dao层）。但是在大型项目中，功能一多，service的优点就很明显了。比如业务处理不仅仅是要联系数据库，还有其他的功能，这个功能很显然不能在dao层中实现（职责规范化），所以就可以在service中调用多个dao层的方法实现复杂业务