架構MVC Web項目/不同類型的模型

UI
核心（服務&模型，實用程序）
庫（ LINQ2SQL）

依賴是

用戶界面 - >核心
核心 - >存儲庫。

我想業務和模式是在自己的組件，並與同時圍繞模型建立的東西最終，即：

UI - >模型，服務
服務 - >模型，庫
庫 - >模型
模型

釷我正在構建的e系統基本上是一個網站CMS，因此我將爲網頁（PageModel）建立一個模型，該網頁包含子網頁集合。 PageModel可以調用服務（PageService）中的方法來填充其子頁面，但是在新設計中不可能發生，因爲Models集合對服務程序集一定一無所知。

我已經考慮過在洋蔥體系結構（即依賴注入）中的一些想法來解決這個問題，但似乎可以使用更優雅/明顯的解決方案。

我是否需要引入另一層模型？查看模型？我認爲我所說的模型是領域模型......我可能錯了！服務將是域服務？

所以我的解決辦法是：

UI - >服務，的ViewModels，模型
的ViewModels - >服務，模型
服務 - >存儲庫，模型
庫 - >模型
模型

在這個例子中，我想像m y PageViewModel將擴展PageModel並使用PageService來獲取它的子頁面。

任何建議讚賞。還有關於這些模型通常被稱爲什麼的指針？我在這裏談論的是DTO模型而不是域模型？和領域模型而不是視圖模型？看起來我提議使用視圖模型並不是視圖模型的工作。

感謝

編輯：

這是我從來沒有最初提到的是，我的領域模型是不是單一的數據庫實體的基本翻譯就像你會在大多數教程看到的。域模型可以包含來自多個相關數據庫表的數據字段。

所以值得擁有一組模型純粹是爲了封裝域中的數據 - 沒有任何方法/屬性來獲取相關對象或將對象保存回數據庫等？ - 數據傳輸對象。

從看一對潦草的圖表，這將意味着在域圖層中有一組映射器（這似乎是錯誤的）將DTO模型翻譯爲域模型並返回。該項目將圍繞DTO模型而不是域模型構建，但給出了DTO封裝的內容，我不認爲這是一個問題。

任何人誰是有興趣的，所提出的依賴結構會像這樣：

UI - >服務，領域模型
服務 - >存儲庫，領域模型中，DTO模式
領域模型 - >庫，DTO模型
映射器 - >域模型，模型DTO
庫 - > DTO模型
DT O型號（無相關性）

這有點混亂！所有這一切都只是因爲我希望我的PageModel能夠獲取自己的子頁面模型。它看起來像是在依賴注入方面可能不是一個壞計劃。

感謝那些已經回覆的人。你給了我很多想法。

來源

2012-02-28 Giles

你可以用洋蔥結構完成這一切。我得例如： UI，域名，數據訪問，服務

UI 服務數據訪問域（包含視圖模型以及）

UI可以訪問任何一個。服務，只有數據訪問和域。數據訪問 - 唯一域。

我的存儲庫接口位於域項目中，它們在數據訪問項目中實現。我還在域項目中保留了其他接口（IContext，IUnitOfWork等），所以我有一箇中心位置，而不是在項目之間傳播太多的接口。

如果您認爲合適，DTO將僅用於在圖層之間進行轉移。對於我來說沒有理由你不能從數據層向上傳遞域模型，有些人選擇在這裏只使用DTO。因爲我可以使用AoP爲我做（[AutoMap（）]屬性），所以我會在UI層（前MVC控制器）中執行映射到ViewModel。

只要記住您的模型不應該包含任何持久性邏輯。

來源

2012-02-28 21:41:37

謝謝亞當。將存儲庫接口放在域中似乎是一種以域爲中心的一切方式的好方法。在持久性點上，我的域模型爲Save（）提供了便捷的方法，它只是在相關存儲庫中調用Save（）方法。你會認爲這是持久性邏輯，因此不好的做法？ – Giles 2012-02-28 22:44:25

雅，他們應該對此一無所知。將實體傳遞到您的存儲庫，並讓它成爲處理所有事情的單一位置。這可以很好地適應工作單元模式，因爲存儲庫可以被重構爲現在實際上將其保存到集合中，並且工作單元實現將該集合保存到一個事務中的數據庫中。您的服務不是調用模型上的Save（），而是知道調用存儲庫實現，該實現應該注入到控制器或存儲庫中。這非常適合測試/嘲笑/等。 – 2012-02-28 22:59:57

我認爲這是非常典型的任何「真實世界」的應用程序以不同的方式存儲數據比顯示在屏幕上的。我認爲你是在正確的軌道上，擁有2個獨立的「模型」。我通常最終打電話給他們：

ViewModels - 映射到屏幕上顯示的內容，視圖需要什麼。
DataModels - 映射到數據庫，什麼持久層（ORM）希望。

有時作爲數據訪問層，或Data Transfer Objects（DTO的）談論實體框架尤其是當DataModels稱爲Entities。

通常有一些組「翻譯」從視圖的數據模型映射的太，或有時可以使用AutoMapper。

當然，如果你正在顯示足夠接近你的數據結構，不存在損害正在通過所有持久/數據模型的意見，但我喜歡讓他們分開了。

來源

2012-02-28 21:50:40 CodingWithSpike

謝謝。我開始懷疑DTO模型。我的模型不一定是來自單個數據庫表的簡單映射。我可能不得不回答我自己的帖子來解釋，雖然.. – Giles 2012-02-28 22:50:46

我已經考慮過在洋蔥體系結構（即依賴注入）中的一些想法來解決這個問題，但似乎可以使用更優雅/明顯的解決方案。

一旦您正確使用依賴注入的懸念，它確實是一個非常優雅/明顯的解決方案。

我建議一個依賴結構是這樣的：

UI
- 控制器 - >服務，模型的ViewModels
- 視圖 - >的ViewModels
- 的ViewModels（無依賴性）
服務 - >存儲庫，模型
庫 - >模型
模型

這是非常接近你有什麼之前，但你的ViewModels是你的UI項目的一部分，在都沒有相關性。他們應該是簡單的類，代表你想要展示給用戶的東西。

這是控制器的工作是：

調用服務來獲得模型，
翻譯模型成的ViewModels和
調用視圖代碼

意見應不需要任何ViewModels不提供的信息。

來源

2012-02-28 22:06:47 StriplingWarrior

謝謝。我認爲依賴注入開始看起來像要走的路。這個項目已經非常複雜了（雖然我的標準......）並且實施DI可能是一個相當大的挑戰。 – Giles 2012-02-28 22:58:50

@Giles：DI有一種傾向，讓你遵循良好的設計模式。由於您一直沒有使用它，所以嘗試使代碼遵循它應該一直使用的模式可能會有一些痛苦。但如果你做得對，DI實際上應該可以幫助你簡化一些事情。祝你好運。 – StriplingWarrior 2012-02-28 23:07:36

架構MVC Web項目/不同類型的模型

回答

相關問題