服務直接推或業務邏輯來處理

Question

更新：

本質而不是有服務器A的服務直接寫入到數據庫或數據表。讓業務邏輯中的服務將值分配給一系列Properties。這樣所有的計算和數據訪問將直接在服務器B上完成。

某些事情可能並不清楚，服務器A是使用該服務的客戶端。

---

所以我有一個獨特的窘境，那就是處理這個特定問題的標準方法。我目前面臨使用服務或內部邏輯的選項。場景：

• 兩個服務器
• 服務器A：推請求到服務器B.
• 服務器B：注意到這些請求和變量，並實現業務邏輯。
• 服務器B：無論如何將要創建關係數據訪問，所以它的工作量增加一倍。

的困境是，我不確定要處理這個標準或最佳方式。我的意思是，將服務器A數據圖直接連接到數據庫會更好嗎？或者更可行的是讓服務器A存儲到屬性然後讓內部邏輯處理它？

我問的原因很明顯，解決方案之一就是快速開發，但會遇到未來的問題或者性能不佳。

如：

• 服務器B：將堅定地填充數據表
• 服務器B：所有在這一點上的持續性將是它自己的從數據庫中檢索數據。
• 隨着項目的發展，可能會很難重構。

這些是我最初的擔憂，所以我傾向於選擇二。但正如我所說，我不確定我的心態是否遵循標準或標準。

爲了避免這被認爲是一場辯論;

做選項1的缺點是否會隨着複雜性的增長而影響任何項目的流動性？方案2的實施是否更加可行，因爲我可以更好地實現直接訪問數據訪問層的通用性？

謝謝你的幫助，希望我明確地表達了我自己的意見，這是有道理的。如果不是，請發表評論，以便我可以相應編輯。

Answer 1

在一定程度上「取決於」。從特定的功能角度來看，任何作品都是正確的。

許多人有許多非功能或設計要求可能會限制或指導特定的實施。例如，如果您的設計應該是面向服務（SOA），那麼每個服務器都應該是自治的。這意味着他們不應該共享數據庫（他們甚至不應該共享一個模式）。在這種以消息爲導向的情況下，通常是一種很好的模式。您可能想要看像消費者/生產者模式和麪向消息的中間件，如隊列或服務總線。在這種情況下，服務器A會將消息（命令）推送給將處理它的服務器B.您可以使用請求/答覆模式來獲得「答覆」回到服務器A.或者，服務器B可以簡單地發送另一個消息（事件）回A以告訴它已完成工作。

更新：

「數據」服務器B使用將完全被在消息中從B發送給它。