在Spring中使用Interceptor来解决业务逻辑问题

Question

我很想定期与Spring合作，所以我有一个基本的设计问题。

拦截器的概念是否应该用于在应用程序中分离出业务逻辑。例如。方法getData从3个类中调用/其中一个需要在到达数据之前进行一些处理。这个处理不像日志记录等问题，似乎在拦截器的例子中更多地使用（我纯粹基于我对Manning书籍的有限阅读），而是应用程序的正确商业逻辑。

我应该在这里使用拦截器还是正常使用拦截器，否则应该使用覆盖？

这是我一般的好奇心，了解拦截器是否只对框架级别的问题有意义吗？

Answer 1

由于你的自定义逻辑执行取决于调用者，而不是被调用的方法，因此使用拦截器确实是一个奇怪的选择。

不知道有关您的确切情况的详细信息，我建议添加另一个执行附加逻辑的方法，然后调用它。如果你在同一个接口上调用3次相同的方法但是有3个底层实现，只需将其他代码附加到其中一个底层实现中。

Answer 2

假设这是针对Spring MVC的，拦截器是一种快速简便的方法，可以全局（或一组页面）应用相同的逻辑，而无需使用单个控制器。

如果有3个组件需要在类中调用相同的方法，但是其中一个组件需要使用该方法执行不同的操作，听起来好像您应该具有提供该方法的类的不同实现。这样，每个组件都可以依赖于提供getData()的组件的接口，并且不需要知道如何实现此方法。