架构事件驱动的建议

最近我一直在使用Spring3.1架构事件驱动的建议

升级我的应用程序工作在事件驱动的架构我是好奇你怎么想：具有在每类中的DAO实例

这（常规方式）
我应该向DAO发送消息（通过jms/channels/whatever），消息的内容将成为我应该做的事情的指示（在DB中插入/更新/ etc记录）

2号方式在松散耦合方式中有多好？

也许这是矫枉过正？

这个或任何其他建议或意见，欢迎。

谢谢。 ray。

来源

2012-10-24 rayman

2只有在确实需要将其拆分为单独的组件并且您有多个使用DAO模块的模块时才有意义，或者出于性能原因（不太可能的情况），您有一组DAO（和分片数据库）的集群。 –

当您说“您有多个使用DAO模块的模块”时。到模块你引用我的项目中的特定类或组件？因为我确实有使用同一个DAO的几个类。 – rayman

模块我是指单独的应用程序。您正在将消息从A发送到B.如果A和B不是单独的应用程序，为什么发送消息而不是方法调用？对于单一应用DI容器（Spring，Guice，CDI）中的松散排列通常就足够了。对于问题中列出的任务，您应该有一个非常具体的需求或用例来使用消息。 –

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

如果你用一个将消息发布到另一个服务的消息客户端替换具体的DAO类注入，你的代码将继续运行，因为它以前没有发生重大变化。当然，阻塞/非阻塞方法之间总是存在脱节，但没有一个好的抽象无法解决。我的建议是查看像Guice这样的框架/库来创建应用程序的初始草稿/重构，而不是添加新图层。如果那样的话，在某些时候您觉得非阻塞的数据库调用是可行的，您可以轻松实现它们。把这个逻辑放在前面只会增加技术债务。

来源

2012-10-24 14:37:20

架构事件驱动的建议

回答

相关问题