我一直在为我当前的一个应用程序在 Spring 之上开发一个简单的基于插件的架构而绞尽脑汁。无论使用像 MVC 这样的模式可以实现多少分离，总是会达到耦合不可避免的地步。
因此，我开始权衡各种选择。起初我认为过滤器是个好东西。我制作的每个插件都是一个过滤器，然后我将简单地将其插入到过滤器映射中。当然，这会在枚举和检查所有过滤器时产生一些开销，但至少， Controller 不必关心数据到达之前发生了什么，或者之后发生了什么，他们只关心获取模型(通过 DAO 或诸如此类)并返回它们。
问题在于并非我所有的应用程序请求都是基于 HTTP 的。有些基于电子邮件，有些是内部安排的(定时)，所以过滤器不会有太大帮助，除非我尝试将每种类型的传入请求调整为 HTTPRequest，这会太多。
我想到的另一个是基于注释的 AOP，我在其中注释每个方法，插件将根据某些约定拦截方法。我的问题是，首先我对一般的 AOP 不太熟悉，其次，简单地编写所有这些约定已经暗示了一些耦合
到目前为止，最符合我的想法的选项是使用基于 Spring 的事件。我的应用程序中的每种类型的请求处理程序(Web Controller 、电子邮件处理程序等)都将是一种事件调度程序，它将在每个主要操作上调度 Spring 事件。另一方面，插件将简单地监听特定事件何时发生，并执行一些逻辑。这也将允许我利用第 1 点，因为其中一些插件也可以是过滤器，即当他们收到某个 Controller 操作已完成的通知时，他们可能只是决定什么都不做，而是等待何时他们被过滤器链调用。我认为这是一种不错的方法。当然，开销又来了，调度事件，加上每个涉及的类都将永远与 Spring 耦合的事实，但我认为这是不可避免的。
我对 Spring 事件的主要关注是性能，包括延迟和内存占用。
我仍然不是专家，所以这里的一堆反馈会很有帮助。 spring events 是最适合这种类型的架构，还是我错过了另一种解决方案？我知道甚至可能已经有一些第三方解决方案了，所以如果有人能指出一两个经过尝试和验证的解决方案，我会很高兴。
谢谢。
最佳答案
插件的概念可以用Spring bean工厂来实现。如果您创建一个公共(public)接口(interface)，您可以定义多个实现它的 bean 并在需要的地方注入(inject)它们。或者您可以使用 factorybean 为工作提供正确的插件。
您使用事件的想法称为“事件驱动架构”。这不仅仅是插件，因为它不仅与实现分离，而且还提供了与使用哪个实例(多个处理程序)、哪个位置(多台机器)和处理请求的时间(异步)分离的可能性处理)。权衡是整体复杂性增加，组件级复杂性降低以及对消息传递基础设施的需求。通常使用 JMS，但如果您只想要单节点设置，则同时使用 Spring 和 Mule还提供简单的内存模式。
为了进一步帮助您，您应该稍微扩展一下您要满足的要求和您想要的架构改进。到目前为止，您已经提到您想要使用插件并描述了一些可能的解决方案，但您还没有真正描述您想要实现的目标。
关于java - 在 Spring 之上开发基于插件的架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8413785/