Java 为什么Spring注释控制器比传统映射更可取？

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

无需扩展基类/实现接口

消除另一个配置文件

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

与使用类扩展/实现相比，使用注释时框架和控制器之间的耦合似乎更紧密

包含映射的单个文件似乎更易于维护，而不是在多个文件中挖掘代码以查找注释

虽然我个人认为上述缺点超过了好处，但注释的使用似乎是首选。这就引出了一个问题：为什么Spring注释控制器比传统映射更可取？

编辑有关耦合的信息：

---

我意识到，在这两种情况下，都与所涉及的底层框架存在某种耦合。Spring所需的

控制器

接口由一个方法组成，大部分可以抽象出来（例如，

接口MyController扩展了SpringController

）。另一方面，注释除了特定于框架之外，还需要在每个文件中导入大量内容。

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

联轴器比较松。带注释的类不依赖于父类方法或接口，可以封装在符合任何框架的类中（如果以后选择迁移）。对于大多数编译器，您仍然需要删除注释，但是代码和逻辑不需要更改，只需要以类似于的方式补充以提供参数和调用流Spring@MVC.

这取决于维护的类型和规模，其中一个是否比另一个更具破坏性。如果您需要更改多个实体的配置，那么在带注释的配置中筛选各种java文件更令人恼火。然而，如果要重构控制器且URL发生更改，那么在java类中进行重构比编辑单独的xml文件（其中包含许多不适用于所做更改的行）具有更少的破坏性

---

还有几个额外的优点：

• 在单个控制器类中对多个操作进行逻辑分组（虽然也可以使用

  MultiActionController

  ，但不太灵活）

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

  HttpServletRequest

  /

  HttpServletResponse

  s

• 使用

  @RequestParam

  ，

  @PathVariable

  等进行映射的额外灵活性（虽然它可以在传统控制器中实现，但由于传统控制器的静态特性，我认为没有注释那么优雅）

---

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

让我来讨论一下缺点：

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

都一样。我两种方法都用过，都不坏。借助现代IDE搜索功能和适当的命名约定，没有单个配置文件也同样容易

---

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

前者指定要为给定请求调用哪个处理程序，后者确定应该如何调用该处理程序

其中一个极端是“经典”SpringMVC，映射用XML定义，适配器由老式的

Controller

类层次结构定义。在另一个极端，您有

@Controller

和

@RequestMapping

，所有内容都在注释中定义

然而，混搭是完全可以接受的。例如，您可以用XML“旧式”定义URL映射，但仍然使用带注释的处理程序类。通过这种方式，您可以避免将URL映射放入注释中（这并不总是一件好事），这样可以保留注释中大大改进的类签名灵活性（并减少对SpringAPI的依赖）

---

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

对我来说，更好的问题是“为什么SpringSource只在其参考手册中记录注释方法？”。他们删除了XML风格的MVC配置文档，我觉得这很烦人。@skaffman是的，这是spring参考的最好部分之一：-）@skaffman它直截了当地说了一句：-），只是要提到spring测试为请求/响应提供了所需的模拟。但是，没有它们还是更好的。如果我不导入相关的Spring代码来支持我的注释，我会得到一个编译错误。@etheros：我是指编译形式。在编译形式中，忽略未知注释。