浅谈MVC、三层架构、多层架构、框架之间的爱恨情仇

浅谈MVC、三层架构、多层架构、框架之间的爱恨情仇

声明：我是初学者，如果你也是那本文也许对你有帮助，因为你遇到的问题可能我也遇到了。

之前MVC，架构，框架之间的概念往往会混淆，为此我记录一下我的短见。如有说错的地方，还望指出。话不多说，主题开始。

先暂不说多层架构地来看度娘对MVC、三层架构、SSM框架的解释：



看完之后你会发现，你已经能够很清楚的区分他们了…才怪(￣▽￣)"。只能算是有个初步的了解。当然，这并不是在说度娘说的有错或者是解释的不到位。度娘说的太官方了，以至于我们这些初学者难以理解。

MVC：

度娘说，MVC是模型-视图-控制器的总称。那什么是模型，什么是视图，什么是控制器呢。
在说这个之前，容我介绍一下我们潮汕美食的特产之一(打波广告撒(～￣▽￣)～)——潮汕红粿。

之间读中学在家就经常帮老妈做这个，不过为了不偏离主题，只提印图案的部分。
其实成品的图案不止上图一种，还有其他一些图案由于网上找不到图就没展示了，不过找到了印图案的工具

不同图案的模具就好比是MVC中的模型，做出来的成品就好比是视图，而我们人就好比是控制器，决定去使用哪一个模具。（可见MVC不仅在代码中适用，在生活也同样适用，毕竟代码的设计灵感本就来源于生活。（￣︶￣）↗　）
现在结合上述的例子来回想MVC在代码中的体现。在MVC中，一些实现特定功能或者是表示一个实体的类就好比模具，而一些使用、调用模型的类就好比我们人，最后执行的结果就好比做出来的成品。可以不成熟的理解为控制器选用特定的模型得到特定的视图。

三层架构：

三层结构是指表现层，业务层，持久层。

表现层：直接与外界交互，作为业务层的客户端，调用业务层。
业务层：业务逻辑判断，作为持久层的客户端，调用持久层。
持久层：直接与数据库交互。
因此，三层架构上和外界交互，下和数据库对接。中间的业务层连接上下两层。
比如说一个系统的登陆，表现层有登陆的入口，业务层有登陆的服务，持久层有查询数据库表的代码。表现层的入口调用业务层的服务，业务层的服务调用持久层的代码，持久层再将查询结果返回给业务层，业务层根据查询的结果做出是否登陆成功的逻辑判断，并将这个判断结果返回给表现层，最后表现层对业务层返回的结果做出相应的反应显示给用户。
此外，各层之间也是互不关心的。表现层不关心业务层是怎么实现的，只关心业务层“登陆成功”，“登陆失败”的结果。同样的业务层也不关心持久层是怎么在数据库中查到数据的，只要相应的结果就够了。也正是因为如此，才能起到解耦。修改任一层的代码都不会影响到其他层。
再者，分层的系统思路清晰，便于后期维护和修改。
不过对于一些简单的不能再简单的小小小小小小…系统，三层架构可能体现不出其优势，甚至还略显麻烦。所以有可能会有这么一种情况，明明是几行代码就可以搞定的东西，非要在每个层都写上代码，先表现层再业务层再持久层。如果出现这种情况，大可不用架构设计。用了反倒有点“杀鸡用牛刀”了。

MVC与三层架构之间的爱恨情仇：

虽然MVC和三层架构之间都有一个数字3，但两者之间并没有什么直接的关系。本就是不同角度的说法。如果非要说个联系，也只能说三层架构中XX层体现了MVC设计中的XX设计，但即使这样也不意味三层架构中的“层”和MVC设计中“M,V,C”一 一对应，数字3只是一个偶然，真一 一对应的话，你让人家多层架构情何以堪…(*￣０￣)ノ。

多层架构：

如果你理解了三层架构，则多层架构也就不难理解，像什么四层架构，五层架构都是三层架构的扩展，延伸，进一步的解耦而已。
四层架构：表现层，服务层，业务层，持久层。
五层架构：表现层，MVC控制层，业务逻辑层，DAO层，Domain Object层

框架：
框架就更好理解了。如果说MVC和三层架构都只是理论知识、纸上谈兵，是虚的，则框架可以说是上战场实战，是实的。也就是将上面有提到的、没提到的一整套理论知识加以运用并经过年代，经验的不断洗礼得出来的精华d=====(￣▽￣*)b。我们只需上官网下载开源的代码即可使用，大大提高了开发效率。
之前流行的是SSH，也就是struts2，spring，hibernate框架。
现在流行的是SSM，也就是springMVC，spring，Mybatis框架。

说的通俗一点就是，MVC是一种设计模式，三层架构是解耦(耦合越低，修改代码影响的范围越小)的方式，框架则是一些牛人，大佬，大神总结出来了一整套科学合理实用的开源代码。