当涉及文件上传时，有两种主要的处理方式：将文件上传逻辑放在控制器(Controller)层和将文件上传逻辑放在服务(Service)层。以下是这两种方式的优缺点：
将文件上传逻辑放在控制器(Controller)层：
优点：
-
简化代码结构： 控制器层负责处理HTTP请求，将文件上传逻辑与请求处理逻辑放在一起，使代码结构更加简洁。
-
方便请求参数处理： 控制器层能够直接处理
MultipartFile等文件上传相关的请求参数，无需进一步转换。 -
便于请求验证： 控制器层可以直接对请求进行验证，确保上传的文件符合系统要求，提高系统的安全性。
缺点：
-
业务逻辑耦合： 将文件上传逻辑放在控制器层可能导致业务逻辑与请求处理逻辑耦合，不够符合单一职责原则。
-
可测试性降低： 控制器层通常较难进行单元测试，将文件上传逻辑放在控制器层可能使测试变得更加困难。
-
不够灵活： 如果未来需要更改文件上传的实现方式或者将文件上传逻辑复用到其他地方，可能需要修改控制器层的代码。
将文件上传逻辑放在服务(Service)层：
优点：
-
职责分离： 将文件上传逻辑放在服务层更符合职责分离的原则，使得控制器层专注于处理请求而不是具体的文件上传逻辑。
-
可测试性增强： 服务层通常更容易进行单元测试，因为业务逻辑可以独立于HTTP请求进行测试。
-
灵活性增强： 如果需要更改文件上传的实现方式或者在其他地方复用文件上传逻辑，只需修改服务层的代码，不影响控制器层。
缺点：
-
增加抽象层： 将文件上传逻辑放在服务层可能需要引入额外的抽象层，增加代码复杂性。
-
请求参数转换： 控制器层需要将HTTP请求中的文件上传参数转换为服务层能够接受的形式。
-
请求验证不直观： 请求验证可能需要在服务层进行，相比控制器层不够直观。
综合考虑，选择将文件上传逻辑放在服务层通常更利于代码的组织、测试和维护，而将文件上传逻辑放在控制器层可能使得代码结构更加简单，适用于简单的文件上传场景。选择适当的方式应基于具体项目的需求和复杂性。
目前我选用的是控制层，确实可以节省很多不必要的复杂配置