技術最前線

  • 發行項

物件和資料模型的藝術

Dino Esposito

 

許多現今的應用程式是架構的單一資料模型，通常保存至資料存放區透過物件關聯對應程式 (ORM) 工具。但有時候，不同的原因，您可能需要更多的彈性，需要多個模型。在本文中我將討論一些您可以處理這種情況下，與開發多個分層和穩固的應用程式使用的策略。

使用不同的模型可清楚地使整個應用程式更複雜，但它是一種的需要，正可以更容易管理整個專案的複雜性。了解當一個模型的資料不適合所有的使用案例是架構設計人員所面臨的挑戰。

軟體應用程式的不同部分可能會有自己的資料模型。您要在 UI 層級的資料表示中的方法是與您組織的中介層中，資料的方式不同，而且可能甚至不同的資料實際如何保存一些資料存放區中。

但是，多年來，開發人員使用的資料，不論相關的應用程式的一部分的單一模型。許多人會成長與關聯式資料庫和其相關的模型技術。很自然的會花費許多心力手段關聯和正規化規則為基礎的模型。儲存在關聯式資料庫中任何資料然後被解壓縮，並使用記憶體結構類似於記憶體中資料庫移動。資料錄集是這種一般的資料模式的名稱 (請參閱 bit.ly/nQnyaf)。 ADO。NET 資料集是很好的實作。

資料表為基礎的方式變得已推入的應用程式日益增加的複雜性的角。ORM 工具一種，為了顧及現實主要的原因有兩個出現。首先，使用物件是比一般的 super-arrays，這類的資料錄集的資料的處理更容易。第二個原因，是產能。ORM 的目標是取得物件模型，並將它對應至關聯式結構描述。藉由使用 ORM，您基本上會使應用程式的觀點來看起來像實際的資料庫物件模型。

您要如何設計此模型?您應該真正使用只是一種模型的每個應用程式吗？讓我們來看一下。

一種模型不一定適合所有

新版本的實體架構 (EF) 4.1 包含支援 」 程式碼第一個 「 程式設計，可做為名稱所示，可以讓 Microsoft。NET Framework 開發人員會將資料模型化程式碼第一種方法。這基本上表示您開始撰寫一般的舊 CLR 物件 (POCO) 模型的類別，在應用程式定義域。第二個步驟組成將這些類別對應至某個持續性存放區，並且有 ORM 工具 (EF) 負責的持續性的詳細資料]。ORM 公開的查詢語言 (LINQ to Entities)、 交易式語意 (EF 中的 xxxContext 物件) 和基本的建立、 讀取、 更新和刪除 (CRUD) API 支援並行處理、 延遲載入和擷取的計劃。

因此您必須在模型中，您知道如何將它保存及查詢從它的資訊。這是您可以在應用程式中所有使用的模型吗？更具體而言，這是您可以有效地回復到展示層的模型吗？這一點很讓人頭痛理論和練習的大幅，不同的內容是國王與不確定性 (如果不完全正確混淆) reigns。我要提供一個實際的範例繫結至受歡迎的 ASP。NET MVC 技術。唯一的理由，我使用 ASP。而不是，說，Silverlight MVC 以及是 ASP。NET MVC 包含文字模型中的名稱 (在 MVC M)，而且我需要太多次在類別和會議中關於 「 模型 」 在 ASP 的確切位置。NET MVC 應用程式。

今天，即使三個版本中，在 ASP 太多的教學課程。NET MVC 堅持使用查詢、 更新和簡報的單一模型。許多教學課程也會保留主專案內的模型的定義。它的運作方式，所以位置的問題嗎？問題不是與方案，它的運作方式，是有效的是我所經常使用自己，並計劃繼續使用。實際上沒有真實世界的一組但簡單且相當短 (不只是示範與教學課程) 的應用程式可以利用簡單的模式。使用單一模型的問題是出在它會傳輸至主要消費者的教學課程的訊息： 開發人員希望了解技術。在一個位置有一個模型建議 (是否不建議使用)，它是慣用的作業風格。是，相反地，只是一種特殊情況，非常簡單且最適合的案例。如果您將在運作的真實案例與相符，您是多個很好。否則，您已阻塞並準備好要增加您第一個 「 大球的泥漿 」 以及更大。

更多的一般架構

讓我們先從使用稍有不同的名稱。現在我們要呼叫的模型您保存網域模型與呼叫資料的資料管理檢視中檢視模式。我要先說明一下該網域模型並不完全的中性詞彙的軟體，因為它指向設計根據其他的規則數目的物件模型。在這份文件的範圍內，我沒有使用後所產生的 Domain-Driven 設計 (DDD) 方法的意義。對我來說，領域模型已只是您所保存的物件模型，實體模型可能是另一個對等用法，並不會混淆，詞彙。

您可以使用類別中的實體模型中的應用程式。 您可以使用類別檢視模型，展示層中。不過請注意，在 ASP。NET MVC，展示層會控制站。控制站應該會收到資料可供 UI。中介層元件接收及傳回檢視模型物件，而且在內部使用的實體物件。圖 1 顯示在典型的多專案的相依性的 web。


圖 1 各階層間的連線

簡報 (也就是程式碼後置或控制器類別) 參考的應用程式邏輯，也就是實作應用程式的使用案例的元件。應用程式邏輯技術所屬的商務層或層，和在非常簡單的情況下可能會與合併簡報。這是發生某些太容易認為需要找出應用程式邏輯中各自的圖層，或設計不良的教學課程和展示和資料存取層 (DAL) 之間的分割應用程式邏輯的狀況。

應用程式邏輯組件實作的服務層的模式，以減少兩接觸層： 展示和資料。實體模型 (您的網域類別) 和 DAL 會參考應用程式邏輯。應用程式邏輯協調 DAL、 網域類別和服務，以此法追蹤預期的行為。應用程式邏輯與展示層透過檢視模型物件進行通訊，並且與 DAL 透過網域物件通訊。DAL，依次參考模型和 ORM 組件。

實體架構的幾個字

讓我們檢查這種架構，假設為 ORM EF。EF 不只是 ORM，但如同其名稱所示，它不會 ORM、 再加上提供用來建立模型的架構的一般工作。好主意，但它不應該被忘記我們正在兩側的兩個不同的圖層，商務和 DAL。類別是商務; 保存引擎是 DAL。EF，保存引擎 (ORM 組件) 是 system.data.entity 和其相依性，包括 ObjectContext 類別。您放入另一種方式，，除非您使用 POCO 類別] 和 [第一個程式碼，可能會得到具有相依性 ORM 網域模型。網域模型應該使用 POCO — 也就是在其他方面，它應該是獨立的組件。這個主題有趣執行緒存在於堆疊溢位在 bit.ly/mUs6cv。如需如何分割實體從 EF 中內容的詳細資訊，請參閱 ADO]。NET 團隊部落格內容項目，「 逐步解說： POCO 範本的 「 實體架構 (bit.ly/bDcUoN) 和"EF 4.1 模型與 資料庫的第一個逐步解說 」 (bit.ly/hufcWN)。

從這個分析，看起來 POCO 屬性是很重要的網域類別。POCO，不用多說，表示具有它自己的組件之外沒有相依性的類別。POCO 是關於簡單起見，而不是錯誤。不會擁有的圖層之間的緊密結合的表單的 POCO 方法方法。緊密結合不 poisonous，且不會刪除您很快地，但是必須花較慢的死亡的專案。簽出我的資料行，有關軟體嚴重損壞，在上個月的問題 (msdn.microsoft.com/magazine/hh394145)。

模型是什麼？

當您建立的物件模型時，您會建立類別的程式庫。您可以組織編號的模式，物件模型，但基本上它能夠以資料表為導向的方法和物件導向的方法之間選擇。

您要如何設定您的類別?他們應該功能哪些功能？特別是，您的類別應該知道的資料庫嗎?他們應該包含邏輯 (也就是方法) 或限制為只公開屬性嗎?有兩個主要模式，您可以參考: 使用中的記錄] 和 [領域模型。

以使用中的記錄模式中，您的類別會密切模型資料庫資料表。您通常會有一個類別，每個資料表和每一資料行的一個屬性。更重要的是，類別是負責自己的持續性和自己簡單、 最小的領域 」 邏輯。

以網域模型] 模式中，根據您的類別被要略提供問題的網域的概念式檢視。這些類別與資料庫沒有關聯性，並將屬性和方法。最後，這些類別並不負責自己持續性。如果您選擇以網域模型的方法，必須委派至不同圖層上保存性 — DAL。您可以自行撰寫這一層，但它不是有趣。為了根據網域模型模式程式庫的 well-done DAL 是 ORM 工具幾乎相同。所以為何不使用其中一個現有的 ORM 工具？

如果您使用自動程式碼產生器，則會 EF 取得所做的只是屬性的類別的物件模型。用的圖樣當然不是使用中的記錄，但是類別有沒有方法，根據預設值。幸運的是，類別會標記為部分，這可以讓您可以藉由加入到部分類別的邏輯圖形總較豐富的網域模型。如果您選擇第一個程式碼的方法，就必須再完全負責從開始到完成撰寫您的類別的原始程式碼。

通常是唯一的功能屬性的物件模型中的類別稱為 anemic 的網域模型。

儲存機制

很好的作法是獲得 well-deserved 的人氣指數包裝外貌類別稱為 「 儲存機制中的資料存取程式碼。儲存機制是由介面及實作類別所組成。您通常需要針對每個儲存機制大模型中的類別。在物件模型中的重要類別是控制它自己的持續性，並代表它自己，而不需視網域中其他類別的類別。在一般情況下，例如，客戶就是重要的類別，而訂單明細，是因為如果您有訂單馬上就要永遠使用訂單詳細資料。在加入 DDD，重要的類別即為彙總的根目錄。

若要改善設計，您可以建立應用程式邏輯，並透過儲存機制介面 DAL 之間的相依性。然後可以在適當的應用程式邏輯中插入實際存放庫。圖 2 顯示結果的架構 DAL 以存放庫為基礎。


圖 2] 使用在 DAL 的存放庫

儲存機制讓相依性中 DAL 的插入，因為您可以輕鬆地拔出目前的模組可提供持續性的邏輯，並取代它。這是依照可測試性，當然有幫助，但它並不限於。DAL 模擬 (mock) 和測試應用程式邏輯中隔離，可讓架構為基礎儲存機制。

存放庫也代表您的應用程式的極佳的擴充性點。取代存放庫，您可以取代的方式，是透明的圖層的其他部份，持續性引擎。此處不太多，切換說，Oracle 到 SQL Server，因此，因為 ORM 工具所提供的彈性，此層級。此處能夠從目前的實作，DAL 的切換至不同的定域機組 API、 動態 CRM、 NoSQL 解決方案和類似的東西。

儲存機制應該不是什麼

儲存機制屬於 DAL; 因此，它不應該了解應用程式邏輯。這可能是太明顯的陳述式，但是我通常看這些日期根據簡報和儲存機制的架構圖表的型別。

如果您實際的邏輯是細且簡單 — 基本上 CRUD 或 — 此圖表是一個以上的 [確定]。但如果不是這樣嗎？如果是的話，您肯定需要您用來部署您應用程式的邏輯中間的位置。和 「 信任 」 我，我看過只有少數的應用程式，只是我的 CRUD。但是可能我沒運氣真好男人 …

釐清隱匿來實現

完成，時至今日應用程式通常專為 ORM 工具然後持續發生某些資料存放區的資料的模型。這是正常的後端應用程式，但不會太對，如果 UI 會要求您處理明顯不同的彙總的只是不存在原始模型中的資料。必須建立專為 UI 的這些新資料型別。最後形成完全平行的物件模型： 檢視模式。如果您減少這兩種模型是只有一個，然後由所有可能是搖桿的並快樂。如果沒有，希望這篇文章 clarified 某些難懂的點。

Dino Esposito＜ 程式設計 Microsoft ASP。NET MVC3 」 (在 [微軟出版品，2011年) 和 coauthor 的 「 Microsoft。NET： 架構的企業應用程式 」 (在 [微軟出版品，2008年)。居住在義大利，Esposito 是在世界各地的產業活動演說。您可以依照他在 Twitter twitter.com/despos。

感謝到下列的技術專家來檢閱這份文件：Andrea Saltarello 和狄 Vega