架构事件驱动的建议答案

【问题标题】：Architecture event driven advice架构事件驱动的建议
【发布时间】：2012-10-24 14:26:29
【问题描述】：

最近我使用 Spring3.1 在事件驱动架构中升级了我的应用程序工作

我想知道你是怎么想的：

在每个需要在数据库中插入/更新/等记录的类中都有一个 DAO 实例。（常规方式）
我是否应该向 DAO 发送消息（通过 jms/channels/whatever），消息的内容将是我应该做什么的说明（在 DB 中插入/更新/等记录）
李>

第 2 种方式在松散耦合方式中的表现如何？

也许是矫枉过正？

欢迎提出此或任何其他建议或意见。

谢谢。射线。

【问题讨论】：

2 仅在确实需要拆分为单独的组件并且您有多个使用 DAO 模块的模块或出于性能原因（而不是不太可能的情况）。
当您说“您有多个使用 DAO 模块的模块”时。到模块您指的是我项目中的特定类或组件？因为我确实有几个类使用相同的 DAO。
模块是指一个单独的应用程序。您正在从 A 向 B 发送消息。如果 A 和 B 不是单独的应用程序，为什么要发送消息而不是方法调用？对于单个应用程序 DI 容器（Spring、Guice、CDI）中的松散耦合通常就足够了。您应该有一个非常具体的需求或用例来为问题中列出的任务使用消息。

标签： java spring events architecture jms

【解决方案1】：

松耦合并不意味着向您的应用程序“添加”更多具体层（消息队列等）。如果“服务”实现类通过接口与 DAO 层交互（想到 Spring DAO bean 注入是一个完美的用例），那么您几乎是在抽象级别进行操作。

如果您随后将具体的 DAO 类注入替换为将消息发布到另一个服务的消息传递客户端，您的代码将继续像以前一样运行，而无需进行重大更改。当然，阻塞/非阻塞方法之间总是存在脱节，但没有什么是好的抽象无法解决的。我的建议是研究像 Guice 这样的框架/库来创建应用程序的初始草案/重构，而不是添加新层。如果那时您觉得非阻塞 DB 调用是可行的方法，您可以轻松实现它们。把这个逻辑放在前面只会增加技术债务。

【讨论】：