一個模型實體，多個頁面->多個視圖？ 多個ViewModel？

Question

由於屏幕空間有限，我將使用多個頁面（連續顯示-思考向導）捕獲單個實體的用戶輸入。 在我的模型中，我希望將此實體建模為單個類是正確的。

在MVVM實現中，我假設將每個頁面視為一個單獨的View是最佳的MVVM實踐。 這個對嗎？

是否在每個頁面都有自己的ViewModel上是否存在關於最佳MVVM的共識，還是應該有一個由多個Pages引用的ViewModel實例？

為了顯示：

選項1

Class A (X, Y, Z)
ViewModelA1 (X)
ViewModelA2 (Y)
ViewModelA3 (Z)
View1 captures ViewModelA1
View2 captures ViewModelA2
View3 captures ViewModelA3

選項2

Class A (X, Y, Z)
ViewModelA (X, Y, Z)
View1 captures ViewModelA.X
View2 captures ViewModelA.Y
View3 captures ViewModelA.Z

Answer 1

“查看”一詞說明了一切。 這是數據視圖。 ViewModel的工作是使來自模型的數據可顯示。 數據需要做的任何事情都發生在視圖模型中，以便視圖可以顯示它。

通常，視圖與視圖模型之間存在一對一的關系，因為通常您只想以一種方式顯示該數據。 （一個“視圖”）我偏離常規做法（可能是MVP模式？）的地方是，如果您想以多種不同的方式顯示數據（例如，您想要條形圖或折線圖，或者餅圖），並且所有視圖的數據都相同，那么您只需要一個viewmodel。 這是DRY原則的案例。 如果您有三個視圖模型並且它們都相同，則使用一個視圖模型。 多個視圖。 一個視圖模型。

Answer 2

我敢肯定有些人會以一種或另一種方式強烈爭論。 從我的角度來看，這完全取決於您需要重用哪些代碼。 既有以視圖為中心的方式又有以模型為中心的方式來構建ViewModel，並且我認為這兩種方法都不總是正確的方法。

如果您發現ViewModels傾向於使用特定於UI的邏輯，則良好的設計將傾向於Views與ViewModels之間的1：1關系，每個ViewModel都包含多個Models。 這種方法的危險在於，您可能需要花費大量代碼將每個ViewModel中的數據連接起來並保持同步，因此需要在每個ViewModel上重復進行此連接。 Uggh。

但是，您可能還會遇到一種情況（就像我在當前項目中所做的那樣），其中ViewModel必須處理基礎模型中的復雜關系，並且可以從多個端點（即用戶或用戶）更新各種Model實體。雙工WCF服務）。 在這種情況下，您需要在每個ViewModel中花費大量時間，以確保其數據與基礎模型同步，並且在每個ViewModel中重新執行所有邏輯是很愚蠢的。 在這種情況下，我發現最干凈的方法是讓您的ViewModels或多或少地以1：1映射模型，並在多個視圖中重復使用。 這種方法的缺點是，您最終可能會從混合到同一類的各種不同視圖中獲得許多特定於UI的代碼，這會使測試和維護變得困難。 （是的，我知道ViewModels應該不與任何特定的UI緊密結合，但是您仍然會得到很多代碼，實際上，“當用戶執行此命令時，它綁定到我我假裝不知道，做其他我不知道會導致出現對話框的事情。“即使在這種抽象級別，編碼到ViewModel中的邏輯也會有所不同。視圖到視圖。）

然后是各種混合方法，這些方法在現實世界中可能是最有用的。 例如，您可能最終在視圖模型中采用了繼承層次結構，以便處理一個或多個基類中的通用連接，然后在繼承鏈中的下一個類中添加特定於UI的部分。

對於它的價值，我對大多數MVVM文章的不滿之一是，它們所處理的過於簡單的場景無法反映您在現實世界中發現的復雜性。 一旦您通過了客戶->訂單-> OrderDetail之類的表格，我發現我閱讀的大多數建議都趨於崩潰，我自己走了自己的路。

Answer 3

教給我有關MVVM的相關最佳實踐（和實踐）：

• 每個頁面/視圖都有一個ViewModel。

• ViewModel應該僅具有與使用它們的View相關的字段/屬性。

• 可以根據需要從多個基礎邏輯模型/類中組合ViewModel。

上面可以提供更多模型，但是隨着時間的推移它們將更易於使用，因為對單個View / ViewModel所做的更改不會影響其他View或ViewModel。

這符合您的第一個選擇 。

Answer 4

在MVVM實現中，我假設將每個頁面視為一個單獨的View是最佳的MVVM實踐。 這個對嗎？

是的，我會根據它的復雜程度來這樣做。 我認為大多數WP7應用程序的MVVM只是一個過大的選擇。

Answer 5

選項1是更好的模型。

我不確定X，Y和Z是什么意思。

您只需將模型的相同實例傳遞給每個ViewModel

Class Model
{
  string X { get;set;}
  string Y { get;set;}
  int Z { get;set;}
}

Class MainViewModel
{
  // constructor
  ViewModel()
  {
    model = new Model()
    SubViewModel = new SubViewModel(model);
  }

  Model model {get;set;}
  SubViewModel sub { get;set;}

}

Class SubViewModel
{
  // ctor
  SubViewModel(Model model)
  {
    this.model = model;
  }

  Model model { get;set;}
}

MainViewModel處理每個SubViewModel之間的導航，但是它們都在查看Model的相同實例，因此它們都具有相同的數據。

Answer 6

在某些任務上，我可能具有與單個ViewModel和該任務的多個視圖關聯的多個模型。 例如，創建具有分組，圖像等的產品。專注於產品。

我也有一些Task，其中Task通過多個View驅動使用多個ViewModel。 例如，在應用程序中創建用戶帳戶，該應用程序具有多個第三方帳戶（如Facebook，Twitter等）的混搭，其中每個第三方API都有其自己的一組要求，但通過一系列步驟對用戶顯示為單個任務。 重點關注用戶帳戶。

MVVM模式根據需要是靈活的。 定義任務，將其分解，然后確定最適合該任務的任務。

Answer 7

看，你在問什么？
我有100萬
我有3個 （假設您最好創建3 V）。

我應該有1個VM還是3個VM？ 換句話說，您問虛擬機概念在哪一側更接近 ？ 在M邊還是V邊？

從我的經驗迄今與模式，虛擬機是更密切相關的V.

因此，您的問題的快速答案是：3個VM（Option1）。 選項2是思考此模式的錯誤方法。