前言：最近在自学搭建一个SpringBoot整合mybatisplus+SpringSecurity 、JWT项目。以前整合mybatisplus时常常在业务逻辑层去继承mybatisplus独有的基础类来实现项目中简单的增删改查又或者在数据层和控制层做逻辑判断。当下科技飞速发展一个框架不能永久使用，框架是要进行不断迭代和更新的，当你身为架构师或者高级程序员时你会怎样搭建框架来顺应历史的潮流？

问题：如何能够快速更换底层框架又能做到减少时间？

MVC分层与三层结构在此特别了解一下。

MVC：MVC（模型M-视图V-控制器C）M 即Model(模型层)，主要负责出来业务逻辑以及数据库的交互，V 即View(视图层)，主要用于显示数据和提交数据，C 即Controller(控制器)，主要是用作捕获请求并控制请求转发。在此特别强调MVC不是二十三种设计模式。关于MVC架构分层只有在SpringMVC中才有体现（可能在其他框架有体现，知识浅薄请谅解）。

三层架构：UI 界面层 BLL 业务逻辑层，DAL数据访问层。在三层结构中常常出现Model这是非常要注意的，在三层架构中是作为实体类的，这也是他们之间的区别的关键所在。在三层架构程序设计中，采用面向抽象编程。即上层对下层的调用，是通过接口实现的。而下层对上层的真正服务提供者，是下层接口的实现类。服务标准(接口)是相同的，服务提供者(实现类)可以更换。这就实现了层间的耦合。

二者区别：二者之间的区别是在于层级的区别，由上可以得出二者之间的层级有些不同。三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决BS应用程序视图层各部分的耦合关系。
相同点：分层与解耦合。从解耦的角度来看他们之间的分层概念其实都一样只是划分不一。

在项目中我们一般把项目按照三层架构的方式分层。要是想顺应历史潮流就应像搭建积木一样将每个版块的内容相互分离之间相互不影响，在分离的基础上在逐渐的搭建。要是在日后优化底层框架的时候就可以实现只取走一块积木其余不变的道理。

我想说的是想要搭建一个稳健可替换的架构就要有良好的分层，让每个版块各司其职。在通俗一点就是别人看你的包名就知道你要做什么知道替换的工程较小。