分层架构
对于一个玩具项目来说,基于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项目的脚手架啦。