导读
查尔斯·狄更斯在《双城记》中写道：“这是一个最好的时代，也是一个最坏的时代。”
移动互联网的快速发展，出现了许多新机遇，很多创业者伺机而动；随着行业竞争加剧，互联网红利逐渐消失，很多创业公司九死一生。笔者在初创公司摸爬滚打数年，接触了各式各样的 Java 微服务架构，从中获得了一些优秀的理念，但也发现了一些不合理的现象。现在，笔者总结了一些创业公司存在的 Java 服务端乱象，并尝试性地给出了一些不成熟的建议。
常见的 Controller 基类如下：
常见的 Controller 基类主要包含注入服务、静态常量和静态函数等，便于所有的Controller 继承它，并在函数中可以直接使用这些资源。
常见的 Service 基类如下：
常见的 Service 基类主要包括注入 DAO、注入服务、注入参数、静态常量、服务函数、静态函数等，便于所有的 Service 继承它，并在函数中可以直接使用这些资源。
首先，了解一下里氏替换原则：
里氏代换原则（Liskov Substitution Principle，简称LSP）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
其次，了解一下基类的优点：
子类拥有父类的所有方法和属性，从而减少了创建子类的工作量；
提高了代码的重用性，子类拥有父类的所有功能；
提高了代码的扩展性，子类可以添加自己的功能。
所以，我们可以得出以下结论：
Controller 基类和 Service 基类在整个项目中并没有直接被使用，也就没有可使用其子类替换基类的场景，所以不满足里氏替换原则；
Controller 基类和 Service 基类并没有抽象接口函数或虚函数，即所有继承基类的子类间没有相关共性，直接导致在项目中仍然使用的是子类；
Controller 基类和 Service 基类只关注了重用性，即子类能够轻松使用基类的注入DAO、注入服务、注入参数、静态常量、服务函数、静态函数等资源。但是，忽略了这些资源的必要性，即这些资源并不是子类所必须的，反而给子类带来了加载时的性能损耗。
综上所述，Controller 基类和 Service 基类只是一个杂凑类，并不是一个真正意义上的基类，需要进行拆分。
由于 Service 基类比 Controller 基类更典型，本文以 Service 基类举例说明如何来拆分“基类”。
根据“使用即引入、无用则删除”原则，在需要使用的实现类中注入需要使用的DAO、服务和参数。
对于静态常量，可以把它们封装到对应的常量类中，在需要时直接使用即可。
对于服务函数，可以把它们封装到对应的服务类中。在别的服务类使用时，可以注入该服务类实例，然后通过实例调用服务函数。
对于静态函数，可以把它们封装到对应的工具类中，在需要时直接使用即可。
2.1.现象描述
我们会经常会在 Controller 类中看到这样的代码：
编写人员给出的理由是：一个简单的接口函数，这么写也能满足需求，没有必要去封装成一个服务函数。
案例代码如下：
访问结果如下：
为什么参数systemName（系统名称）没有被注入值？《Spring Documentation》给出的解释是：
Note that actual processing of the @Value annotation is performed by a BeanPostProcessor. BeanPostProcessor interfaces are scoped per-container. This is only relevant if you are using container hierarchies. If you define a BeanPostProcessor in one container, it will only do its work on the beans in that container. Beans that are defined in one container are not post-processed by a BeanPostProcessor in another container, even if both containers are part of the same hierarchy.
意思是说：@Value是通过BeanPostProcessor来处理的，而WebApplicationContex和ApplicationContext是单独处理的，所以WebApplicationContex 不能使用父容器的属性值。
所以，Controller 不满足 Service 的需求，不要把业务代码写在 Controller 类中。
SpringMVC 服务端采用经典的三层架构，即表现层、业务层、持久层，分别采用@Controller、@Service、@Repository进行类注解。
表现层（Presentation）：又称控制层（Controller），负责接收客户端请求，并向客户端响应结果，通常采用HTTP协议。
业务层（Business）：又称服务层（Service），负责业务相关逻辑处理，按照功能分为服务、作业等。
持久层（Persistence）：又称仓库层（Repository），负责数据的持久化，用于业务层访问缓存和数据库。
所以，把业务代码写入到Controller类中，是不符合SpringMVC服务端三层架构规范的。
把持久层代码写在 Service 中，从功能上来看并没有什么问题，这也是很多人欣然接受的原因。
业务层和持久层混杂在一起，不符合SpringMVC服务端三层架构规范；
在业务逻辑中组装语句、主键等，增加了业务逻辑的复杂度；
在业务逻辑中直接使用第三方中间件，不便于第三方持久化中间件的替换；
同一对象的持久层代码分散在各个业务逻辑中，背离了面对对象的编程思想；
在写单元测试用例时，无法对持久层接口函数直接测试。
戳一下上面软广，支持开源君的日常推文！
这里以数据库持久化中间件 Hibernate 的直接查询为例。
阿里的 AliGenerator 是一款基于 MyBatis Generator 改造的 DAO 层代码自动生成工具。利用 AliGenerator 生成的代码，在执行复杂查询的时候，需要在业务代码中组装查询条件，使业务代码显得特别臃肿。
个人不喜欢用 DAO 层代码生成插件，更喜欢用原汁原味的 MyBatis XML 映射，主要原因如下：
会在项目中导入一些不符合规范的代码；
只需要进行一个简单查询，也需要导入一整套复杂代码；
进行复杂查询时，拼装条件的代码复杂且不直观，不如在XML中直接编写SQL语句；
变更表格后需要重新生成代码并进行覆盖，可能会不小心删除自定义函数。
当然，既然选择了使用 DAO 层代码生成插件，在享受便利的同时也应该接受插件的缺点。
把一个 Redis 对象相关操作接口封装为一个 DAO 类，符合面对对象的编程思想，也符合 SpringMVC 服务端三层架构规范，更便于代码的管理和维护。
上面的代码，看上去是满足 SpringMVC 服务端三层架构的，唯一的问题就是把数据库模型类 UserDO 直接暴露给了外部接口。
存在问题：
间接暴露数据库表格设计，给竞争对手竞品分析带来方便；
如果数据库查询不做字段限制，会导致接口数据庞大，浪费用户的宝贵流量；
如果数据库查询不做字段限制，容易把敏感字段暴露给接口，导致出现数据的安全问题；
如果数据库模型类不能满足接口需求，需要在数据库模型类中添加别的字段，导致数据库模型类跟数据库字段不匹配问题；
如果没有维护好接口文档，通过阅读代码是无法分辨出数据库模型类中哪些字段是接口使用的，导致代码的可维护性变差。
解决方案：
从管理制度上要求数据库和接口的模型类完全独立；
从项目结构上限制开发人员把数据库模型类暴露给接口。
下面，将介绍如何更科学地搭建 Java 项目，有效地限制开发人员把数据库模型类暴露给接口。
共用模型的项目搭建，把所有模型类放在一个模型项目（example-model）中，其它项目（example-repository、example-service、example-website）都依赖该模型项目，关系图如下：
风险：表现层项目（example-webapp）可以调用业务层项目（example-service）中的任意服务函数，甚至于越过业务层直接调用持久层项目（example-repository）的DAO函数。
模型分离的项目搭建，单独搭建API项目（example-api），抽象出对外接口及其模型VO类。业务层项目（example-service）实现了这些接口，并向表现层项目（example-webapp）提供服务。表现层项目（example-webapp）只调用API项目（example-api）定义的服务接口。
风险：表现层项目（example-webapp）仍然可以调用业务层项目（example-service）提供的内部服务函数和持久层项目（example-repository）的DAO函数。为了避免这种情况，只好管理制度上要求表现层项目（example-webapp）只能调用API项目（example-api）定义的服务接口函数。
服务化的项目搭，就是把业务层项目（example-service）和持久层项目（example-repository）通过 Dubbo 项目（example-dubbo）打包成一个服务，向业务层项目（example-webapp）或其它业务项目（other-service）提供API项目（example-api）中定义的接口函数。
说明：Dubbo 项目（example-dubbo）只发布 API 项目（example-api）中定义的服务接口，保证了数据库模型无法暴露。业务层项目（example-webapp）或其它业务项目（other-service）只依赖了 API 项目（example-api），只能调用该项目中定义的服务接口。
如果从SpringMVC服务端三层架构来说，这是不允许的，因为它会影响三层架构的独立性。但是，如果从快速迭代开发来说，这是允许的，因为它并不会暴露数据库模型类。所以，这是一条不太建议的建议。