查看模型和依賴注入

Question

在使用PRISM和Enterprise Library進行大量CRUD操作的LOB桌面應用程序時，我注意到一個看似煩人的重復模式。 對於每個域模型實體（例如，Contact），我發現我用視圖模型（例如ContactVM）自我包裝然后我引入一個新的ContactsVM （注意's'），其中后一個類接受一個存儲庫接口，用於填充一個ObservableCollection<ContactVM> ，對於我從存儲庫中讀取的每個Contact實體，我將它包裝在ContactVM ，我將實體傳遞給構造函數以及我的ViewModel所需的其他企業庫服務。

問題是我的所有視圖模型構造函數都開始采用這樣的模式：

ViewModel(EntityToWrap e, DependencyFromEntLib, OtherDependencies ...)

現在這是一個問題，因為大多數工具和庫需要默認的無參數構造函數（例如，某些商業數據網格需要提供過濾支持），而且您不能使用設計數據來實現實體可視化，因為它們也需要無參數構造函數。 最后一個問題：構建視圖模型的正確方法是什么？應該通過構造函數還是通過ServiceLocator提供Entlib服務？

Answer 1

以下是解決問題的許多不同方法之一。

我更喜歡更輕量級的視圖模型。 然后我添加一個類，其職責是從一個或多個源（例如存儲庫）組成視圖模型。 這並沒有消除級聯依賴的問題，但它確實釋放了視圖模型構造函數。

它還保留了控制器之外的邏輯，並允許重用視圖模型（當然，適當時）。

• 輕量級視圖模型

• 輕量級控制器知道如何定位組裝視圖模型的作曲家（您可以使用DI框架來設置具有所有依賴關系的作曲家）。 控制器可能在設置過程中起到次要作用，但應保持簡單。

• Controller知道如何組裝視圖模型，並與composer類共享。 例如，該操作可能會請求一個摘要視圖，該摘要視圖仍然可以利用相同的視圖模型而不填充子項。

• Composer匯集了完成視圖模型所需的信息。 作曲家可以使用其他作曲家來收集不直接負責的信息。 同樣，這里可以使用DI框架，以便為這些作曲家提供他們需要的依賴關系。

• 控制器像往常一樣使用完成的視圖模型呈現視圖。

在我看來，這也提供了更好的抽象層次。 僅僅因為視圖模型通常看起來像特定的域模型，這並不意味着它總是如此。

最終結果：

• 很多類（缺點，授予），但代碼重復最少（即DRY）

• 可測試的薄視圖模型（如果需要......它們可能無需測試）

• 薄，可測試的控制器。

• 可測試的作曲家對象，可以重復用於不同的場景，因為他們（可能）知道如何為各種目的組裝視圖模型。

• 靈活地混合和匹配視圖模型，控制器和編輯器，以支持不同的場景。