架構事件驅動的建議

最近我一直在使用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

架構事件驅動的建議

回答

相關問題