數據所有權和性能

Question

我們正在設計一個新應用程序，並在思考數據所有權時遇到了一些架構問題。

我們將系統分解爲組件，例如Customer和Order。每個組件/模塊都負責特定的業務領域，即客戶處理客戶的CRUD和以客戶爲中心的業務流程（註冊新客戶，阻止客戶賬戶等）。每個模塊都是一組數據庫表的所有者，只有該模塊可以訪問它們。如果另一個模塊需要另一個模塊擁有的數據，它將通過從該模塊請求數據來檢索它。

到目前爲止這麼好，問題是如何處理情景，如需要向所有客戶展示所有客戶以及爲每個客戶提供他所有訂單的報表？在這種情況下，我們需要從Customer模塊中獲取所有客戶，遍歷它們併爲每個客戶獲取Order模塊中的所有數據。性能不會很好......顯然，存儲proc加入客戶表和訂單表會更好，但這也意味着直接訪問另一個模塊擁有的數據，從而創建耦合和依賴關係，我們希望避免。

這是一個簡化的例子，我們正在處理一個有很多業務實體和關係的企業應用程序，我的目標是保持它的乾淨和儘可能鬆散耦合。我預計未來會對數據方案進行很多更改，並可能將系統分成幾個完全獨立的系統。我希望有一個能夠以相對簡單的方式完成這項工作的設計。

Answer 1

我想說這是存儲庫模式的一個很好的例子，您可以在其中定義一個包含所有數據邏輯的接口（或其中的一小部分）。然後通過IoC將這個接口的實現傳遞給組件。

雖然這種模式並不能很好地解決耦合問題，但報告庫可以瞭解客戶表，但至少知識將包含在少數類中。 （理論上你可以把報告邏輯放在客戶資源庫中，但這不是最好的做法，因爲用戶比報告更「原始」，但它取決於系統，但意味着更少的耦合）

你可以獲取有關存儲庫模式的更多信息here和here

Answer 2

對於不同級別的解決方案，您可以擁有不同的所有者（或所有權哲學）。

它可以適用於基於物理架構的數據所有權（儘管情況並非總是如此）。一旦你到達業務邏輯層，你可能會有一個全新的「所有者」和範圍 - 這些將擁有他們展示的「視圖」（數據片），但不是數據的單個位補充。我認爲這完全沒問題。

即使在存儲過程級別，這也沒有問題。僅僅因爲擁有某物並不意味着它不能共享。

Answer 3

我會建議在這裏

• 這兩種方法的一個使用你的例子，如果你正在構建企業系統報表的需要，你應該考慮去耦從代碼中報告的實施，並利用報告框架拉來自數據存儲的數據並呈現它。您將有意識地決定繞過您的業務領域層
• 第二個建議是創建一個新的表示域層，它將爲您的系統提供只讀數據，在這種情況下，它可以獲取/準備非規範化數據或DTO爲個人報告需要。提供這些數據的後端數據層可以是您的編程環境中可用的存儲過程或其他機制（例如.NET中的LINQ），它們將爲您提供所需的性能。所有的事務操作仍然需要通過業務領域層，因爲表示層只提供只讀操作和對象。

Answer 4

你有2種一般形式的目標責任 - 只讀CRUD &。 客戶和訂單模塊擁有他們各自的數據（表，權利等），偶爾與他人分享。

我只會選擇所有權可能的最快，最有效的形式 - 不需要報告模塊從您的標準業務模塊要求任何東西。您的業​​務模塊將承擔其他責任。報告需要儘可能使用存儲過程作爲獨立的模塊運行，具有自己的一套規則，訪問等。

Answer 5

我對同一個問題採用了不同的方法：每個模塊都有自己的接口，對嗎？在這種情況下，接口指的是一個編程接口，如EJB接口（在java中）或.h文件（在舊的普通C中）等等。但是如果你有單個數據庫（即使每個模塊擁有一組表，你可能擁有一個單一的數據庫），你可以將你的接口的一部分作爲數據庫中的一個視圖公開。在這種情況下，每個模塊將定義一組編程接口和一組「DB接口」，僅用於查詢目的。您將能夠使用簡單的SQL和連接來讀取報告的數據，並且只能訪問模塊想要公開的內容。