Repository I - Why

圖書《商業級 ASP.NET MVC 樣式與架構實務》
Repositories II - How To

物件透過建構式或是工廠建立,並由程序調用,過程中如果是根物件,根據領域聚合規則,直接建立即可,其它物件則需透過關聯取得,由於大型系統的複雜度,經由關聯存取物件是個負擔,我們一方面利用隔離介面設計,期望降低物件彼此間的耦合性,將因為物件關聯的設計而再度上升,現代系統的設計,基礎架構層均提供了支援物件狀態儲存的資料庫系統,讓實體物件狀態能夠維持永久的持續性(Persistence),因此除了實值物件狀態經由根實體關聯屬性存取,對於特定的實體,事實上我們習慣透過資料庫系統直接取得需要的實體物件封裝資料,並進行其狀態維護。



以訂單系統中的 Order 聚合為例,建立Order根物件之後,透過關聯屬性 AddressInfo 來取得實值物件,但 OrderLines 是實體集合物件,這個部份屬於持續性的資料,儲存於資料庫中,因此透過資料庫也可以直接取出,事實上在一般系統開發中,我們確實也是經常如此處理,不過因為可以直接取出,這破壞了領域的聚合封裝原則,如果透過關聯,從 Order 根物件再往下取出 OrderLines。

過去我們依賴 ADO.NET 進行資料庫存取,如上圖,為了方便均是直接編輯 SQL 敘述傳入資料庫引擎,再將結果轉換為需要的實體物件進行操作,這讓存取邏輯完全曝露於程式碼中,當系統持續發展,相關的程式碼充斥其中,對於領域模型的發展將有不良的影響。



現在透過 Entity Framework 結合 LINQ 存取需要的資料,直接取得實體並結合領域模型操作,可以解決 SQL 的問題,如下圖:



另外一個問題是,相較於透過關聯屬性存取,直接透過資料庫存取實體狀態雖然方便,但如此一來將讓應用程式難以維護聚合定義的完整性。

除了透過  Entity Framework 簡化 ADO.NET 建立實體的複雜度,開發人員必須特別關注領域模型在實際開發時面對的兩難,當我們為了維護領域模型,透過關聯存取實體物件會升高耦合度並降低領域模型的彈性,允許實體物件直接從資料庫取出,則會破壞領域原則,在這種情形下,我們必須另外透過其它的方式,來取得需要的實體物件,建立 Repository 可以解決這裏的問題。

Repository 同樣由類別進行實作,配置於基礎架構層,封裝管理實體狀態所需的程序,包含資料庫連線,並儲存物件狀態,領域模型接下來不需要考量存取資料庫的問題,只要在需要的時候,透過存取庫取得即可。

Repositories II - How To
圖書《商業級 ASP.NET MVC 樣式與架構實務》

沒有留言: