《Java工程师必读手册》——Java经验之谈系列——那些年，我们见过的Java服务端“乱象”（2）

接上篇：https://developer.aliyun.com/article/1228262?groupCode=java

二、 把业务代码写在Controller中

1. 现象描述

我们会经常会在Controller类中看到这样的代码：

编写人员给出的理由是：一个简单的接口函数，这么写也能满足需求，没有必要去封装成一个服务函数。

2. 一个特殊的案例

案例代码如下：

访问结果如下：

为什么参数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来处理的，而WebApplicationContext和ApplicationContext是单独处理的，所以WebApplicationContext不能使用父容器的属性值。

所以，Controller不满足Service的需求，不要把业务代码写在Controller类中。

3. 服务端三层架构

SpringMVC服务端采用经典的三层架构，即表现层、业务层、持久层，分别采用@Controller、@Service、@Repository进行类注解。

• 表现层（Presentation）

又称控制层（Controller），负责接收客户端请求，并向客户端响应结果，通常采用HTTP协议。

• 业务层（Business）

又称服务层（Service），负责业务相关逻辑处理，按照功能分为服务、作业等。

• 持久层（Persistence）

又称仓库层（Repository），负责数据的持久化，用于业务层访问缓存和数据库。

所以，把业务代码写入到Controller类中，是不符合SpringMVC服务端三层架构规范的。

接下篇：https://developer.aliyun.com/article/1228260?groupCode=java