分层架构
对于一个玩具项目来说，基于servlet开发的前后端系统，后端可以提供一个接口，然后所以的逻辑其实都可以在这个接口里实现，最终这个接口实现的方法就会有几十行上百行甚至更多。但是实际上这并不符合真正的设计规范。在实际的开发项目中，由于需求之间可能会有复用，以及解耦的考虑，那么就该使用出色的结构思想去设计项目基本的脚手架。
比如说一个类所需的内容很多，如一系列的属性，一堆的方法实现，一堆的接口，那么其实就需要合理的把这些内容分配到不同的层次去实现，因此就有了分层架构的思想。
编程三步
如果想将不同的内容划分到不同的层次中，那么就应该将不同的内容划分出来。如图所示，其实就包含了一个玩具项目的基本所需了，如定义属性中，前端访问后端的接口，可能会传递过来很多参数，如最简单的登陆接口，需要username和password，那么就应该存在这样一个user对象，也就是请求对象，也是实体对象。当然也有请求对象与实体对象不一致的情况。同样的，如果返回的内容很多，那么也应该封装成一个对象。
在业务中，可能也需要组合不同的实体类当做一个业务对象。
以及对系统中一直固定常用值做枚举类，省得万一修改还需要全局到处去修改。
而创建方法中，实际上是要将对应业务方法封装抽离出来，最常见的就是数据库操作方法和业务逻辑方法。
最后在调用展示中，其实利用定义属性和创建方法里面封装好的内容，完成整个接口请求以及接口响应。
分层架构
MVC架构之所以叫MVC，是因为其主要包括三个部分，M model对象层，都封装到了domain里面；V view展示层，但是目前项目基本上都是前后端分离的项目，所以基本上都快放弃了以前JSP的写法；C controller 控制层，对外提供实现类。
其实吧就是将编程三步中所涉及到 都分配到MVC的各个层次中去。这样分层过后，就可以很清晰的知道各个层次都在做什么内容，利于后续管理的维护和迭代。
对于一个真正的项目来说，是没有一锤子买卖的，最开始的开发远不是成本所在。最大的开发成本是后期的维护和迭代。而架构设计的意义更多的是解决系统反复的维护和迭代时，如何降低成本，这也是架构分层的意思所在。
调用流程
首先发起接口请求，Controller收到请求后，调用Service层的业务方法，然后Service调用Dao层的业务方法。当执行完成后，逐层的返回Controller中封装数据，然后以响应对象的方式 进行接口响应。
架构树形结构
└─src ├─main │ ├─java │ │ └─cn │ │ └─potato │ │ └─mvc │ │ ├─common │ │ │ Contants.java │ │ │ Result.java │ │ │ │ │ ├─controller │ │ │ TestController.java │ │ │ │ │ ├─dao │ │ │ │ ITestDao.java │ │ │ │ │ │ │ └─impl │ │ │ TestDaoImpl.java │ │ │ │ │ ├─domain │ │ │ ├─po │ │ │ │ Test.java │ │ │ │ │ │ │ ├─req │ │ │ │ TestReq.java │ │ │ │ │ │ │ └─res │ │ │ TestRes.java │ │ │ │ │ └─service │ │ │ ITestService.java │ │ │ │ │ └─impl │ │ TestServiceImpl.java │ │ │ └─resources │ │ application.yml │ │ │ └─mybatis │ └─mapper │ TestMapper.xml │ └─test └─java └─cn └─potato └─mvc Test.java
由于我使用的机器上配置过WSL2，所以 可以在项目根目录中直接使用 tree -f命令获取到项目的树结构，没有配置过的可以参考这篇文章你还在为买不起云服务器而烦恼吗？（本地化部署windows解决方案，适用于学生党的部署方案）-CSDN博客
以上就是一个mvc项目的脚手架啦。
