WPF - MVVM體系結構（Visual Studio解決方案和項目）

我正在MVVM模式中開發Window-App WPF項目。目前，該應用程序有點簡單（不能真正解釋產品的性質），但最終它有望成爲更復雜的應用程序。WPF - MVVM體系結構（Visual Studio解決方案和項目）

wpf winapp有一個本地數據庫，也連接到一個REST服務。
開發時間並不是真正的首要關注點;但可維護性和可測試性。
將使用一個IOC容器和DI
規劃做1視圖模型是：1個瀏覽
我不希望使用任何WPF/MVVM框架，因爲這是我在WPF的MVVM應用程序第一次（就像第一次在裸露的DOM中編寫javascript一樣，即使有jquery也是如此）。

我決定使用多個項目，這裏就是我想出迄今：

Product.Windows.Common（utils的，記錄，助手等）
產品.Windows.Entities（數據庫和REST實體）
Product.Windows.Contracts（所有接口將駐留在此名稱空間/項目中）
Product.Windows.Data（本地數據庫）
Product.Windows.ServiceClients（爲REST客戶端）
Product.Windows.App（主WPF項目，包含了瀏覽/ XAML ）
Product.Windows.Models（INPChanged）
Product.Windows.ViewModels（INPChanged和個ICommand）
Product.Windows.Tests（單元測試）

我只想問：

是這種架構有點過殺人？
我是否需要爲業務邏輯創建一個Product.Windows.Business？或者我應該把商業邏輯放在ViewModels中？

預先感謝您:)

來源

2014-07-09 JL Dajoyag

*很多很好的問題基於專家的某種程度的意見經驗，但對這個問題的回答往往幾乎完全基於意見，而不是事實，參考或具體的專業知識。*因此，我已投票結束這個問題。 – Sheridan

我目前工作的一個應用程序具有相似的結構。項目結構看起來不錯。在我的項目中，我做了一些不同的事情。

Data和ServiceClients程序集可能代表您的DAL。它們在不同的程序集中是分開的。在數據彙編中您將擁有存儲庫，而在ServiceClient中您將擁有服務代理。實體和合同組件可能代表你的BL。在這裏，我想你可以使用一個組件。這個程序集應該被兩個DAL程序集引用。

記錄單獨實施是很好的，如果你有安全性，這也應該在Common中實現。從我最近閱讀的一本很好的書，.NET中的依賴注入，utils &助手是糟糕/不完整設計的結果。這些類通常包含靜態方法。但我認爲這與討論無關。

在我的項目中，我通常在與視圖相同的程序集中實現虛擬機。這包括RelayCommand（ICommand實現）和實現INPC的ViewModelBase。

我最近查看了Robert Martin的演示文稿。從我記得的他說，應用程序的架構應該尖叫應用程序的功能。不應將類分組到名爲（MVC或MVVM）的項目或文件夾中。這告訴我們什麼應用程序沒有做什麼。應該按照他們所做的功能來分類。我還沒有在這個階段。我仍然像你一樣分組:)。

我看到你只有一個測試項目。如果你在這個項目中爲你打算測試的所有程序集添加目錄，這也可能沒問題。如果你沒有這樣做，那麼找到特定裝配的測試會有點困難。您可能需要爲計劃測試的每個裝配添加測試項目。

來源

2014-07-09 07:10:51

謝謝@flo_badea的想法:) p2 - 很好，我們同意數據和服務客戶端。 p3 - 是的，計劃將安全性通用。我可能仍然會繼續使用，在應用程序和幫助程序上使用DI（對於未來可能會有多種實現） p4 - 感謝將它們結合起來的想法。也會考慮這個問題 p5 - 關於它的偉大想法！ p6 - yup，計劃在測試項目中爲每個程序集添加文件夾。 –

一想到，我認爲你是對的。我將切換到使用靜態方法將utils/helpers作爲類。 –

我的意思是utils是這些utils類通常包含靜態方法。根據我讀過的這是由於設計不足。我會給你作爲我的治療項目的例子。到目前爲止它不包含任何utils類。順便說一句，我沒有提到這一點，你應該嘗試使用DI，如果你感覺舒服。我在我目前的項目中也是這樣做的。這是我第一個將DI應用於一切的項目，它的接縫效果非常好。該應用程序也是高度可測試的。 –

你可以組織你的組件，只要你想，但我prefere以下結構： - 的創建項目中的每個畫面2類庫（DLL）（一個他們有這個屏幕的視圖+視圖模型，其他DLL有它的業務邏輯），所以你可以使用你的視圖和視圖模型與另一個業務邏輯，也可以更改，更新每個屏幕業務/視圖分開，更新將當你更換一個DLL時工作。

使用所有的組件，除了： Product.Windows.ViewModels Product.Windows.Models

來源

2014-07-09 07:07:50

實際上，人們不會在另一個應用程序中重新編譯_same_視圖和_same_視圖模型。您的視圖爲您的演示模式量身定製，您的視圖模型針對您的應用程序邏輯和數據模型量身定製。應用程序之間共享的空間很小。 – Gusdor

好吧，在我的情況下，我在應用程序之間共享屏幕視圖，但是您可以爲每個屏幕使用一個dll（視圖+ viewmodel + business）。 –

我有超過25種不同的意見。我真的想要25個dll嗎？ – Gusdor

這是有點矯枉過正，但我認爲只有你可以擔保自己的程序。我想我會把合同裏面共同和實體（根據功能）。另外，我認爲你不需要在View和ViewModel之間完全分開。如果他們在同一個項目上，它還可以簡化更改/調試過程。
如果你的程序只是客戶端，你可以在ViewModel中使用BL（至少如果它沒有太複雜的話）。如果你有一個主服務器和多個客戶端，那麼你不應該在你的ViewModel實施任何邏輯（除化妝品），並且是創建一個新項目

來源

2014-07-09 07:15:25

謝謝！＃1 - 好主意，我將模型和視圖模型合併到主要的WPF應用程序中（很像控制器在ASP.NET MVC項目中的方式）＃2 - 這是客戶端，因此對ViewModel內部的邏輯有1票。 –

WPF - MVVM體系結構（Visual Studio解決方案和項目）

回答

相關問題