为什么Spring注释控制器优于传统映射？

Question

据我了解，Spring中带注释的控制器有两个主要好处：

1. 无需扩展基类/实现接口。
2. 删除了另一个配置文件。

然而，这似乎带来两个主要缺点：

1. 与使用类扩展/实现相比，使用注释时框架和控制器之间的耦合似乎更紧密。
2. 包含映射的单个文件似乎更容易维护，而不是在寻找注释的多个文件中挖掘代码。

虽然我个人认为上述缺点超过了益处，但注释的使用似乎更受欢迎。这让我想到了一个问题：为什么Spring注释控制器优于传统映射？

关于耦合的编辑：

我意识到在这两种情况下都存在与所涉及的底层框架的某种耦合。 Spring所需的Controller接口由单个方法组成，并且可以大部分被抽象出来（例如interface MyController extends SpringController）。另一方面，注释除了特定于框架外，还需要在每个文件中进行大量导入。

Answer 1

让我争论一下这些缺点：

1. 没有。这是可以在不影响功能的情况下轻松消失的元数据。另一方面，必须扩展某些类，并使用他们的方法，这使得以后无法摆脱框架。

2. 它是一样的。我已经使用了这两种方法，也没有坏。借助现代IDE搜索功能和适当的命名约定，没有单一的配置文件也同样容易。

Answer 2

还有其他几个优点：

• 在单个控制器类中对多个操作进行逻辑分组（虽然也可以使用MultiActionController，但不是那么灵活）

• 简化单元测试，因为在大多数情况下，您可以传递简单的参数，而不需要准备模拟HttpServletRequest / HttpServletResponse。

• 使用@RequestParam，@PathVariable等进行映射的额外灵活性（虽然它可以在传统控制器中实现，但我认为由于传统控制器的静态特性而不像注释那么优雅）。

此外，我不能同意第一个缺点 - 在我看来，注释引入的耦合少于继承。例如，您甚至可以使用已编译的带注释的控制器作为常规类，而不在类路径中使用Spring（尽管编译带注释的源代码仍需要在构建路径中进行注释）。

Answer 3

我认为单个文件不易维护。我发现一个很大的注释是注释允许你使用多个项目中的对象，并且他们带来了他们的配置。我不必编辑源代码，然后记住每个使用它的项目并修复其配置文件。它创造了一种更加模块化的思维和发展方式。

Answer 4

1. 耦合更松散。带注释的类不依赖于父类方法或接口，并且可以封装在符合任何框架的类中，以后您是否应该选择迁移。您仍然需要删除大多数编译器的注释，但代码和逻辑不需要更改，只需补充以提供与Spring @ MVC类似的参数和调用流程。

2. 这取决于维护的类型和规模，一方是否比另一方更具破坏性。如果您需要更改多个实体的配置，则在带注释的配置中筛选各种java文件会更加烦人。如果您正在重构控制器并且URL更改，那么在java类中执行此操作将比编辑单独的xml文件（其中包含许多不适用于所做更改的行）具有更少的破坏性。

Answer 5

除了现有的答案之外，我觉得值得一提的是Spring MVC在处理程序映射和处理程序适配器之间进行了清晰的分离。

前者指示要为给定请求调用处理程序，后者确定应该调用该处理程序的 。

一个极端，你有“经典”的Spring MVC，其中的映射是用XML定义的，而适配器是由旧式的Controller类层次结构定义的。在另一个极端，您有@Controller和@RequestMapping，并在注释中定义了所有内容。

然而，混合搭配完全可以接受。例如，您可以在XML中定义URL映射，“旧式”，但仍然使用@Controller - 带注释的处理程序类。这样，您就可以避免将URL映射放入注释中（这并不总是一件好事），这样可以保留批注的大大提高的类签名灵活性（并减少对Spring API的依赖性）。

这种混合方法的能力意味着你几乎可以定义最适合你的方法。