爲什麼我應該在Silverlight應用程序中使用MVVM？

我想知道爲什麼我們應該使用MVVM來實現Silverlight應用程序。這有什麼好處？爲什麼我應該在Silverlight應用程序中使用MVVM？

我們不對ViewModel進行單元測試，所以我想要其他原因。

下面是我的一些優點，人們平時所說的問題：

1.Loosely加上：當我們使用MVVM，視圖依靠視圖模型而不是一個視圖，它爲什麼鬆散耦合？

2.如果我在代碼隱藏中提供公共方法，它們也可以提供可重用性。

2011-01-07 Jason Li

如果提供屬性和命令在一個隱藏的代碼，並使用它們綁定「this.DataContext =這一點;」，這是一個視圖模型太。只是不要使用像'this.firstNameTextBlock.Text = this.CurrentItem.FirstName;'的代碼 – vorrtex 2011-01-07 11:35:31

我認爲這是最好的資源之一，如果你想使用和對比使用MVVM與任何其他模式或沒有模式。

http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/

來源

2011-01-07 03:19:51

好了，視圖模型的單位可測試性是一個顯著的優勢，所以你對這種福利錯過。至於其他兩個：

鬆耦合

是，該觀點並依靠視圖模型。它們必須以某種方式連接才能完成應用程序的功能。因此，他們不能脫鉤。唯一的選擇是緊密耦合或鬆散耦合或介於兩者之間。使用MVVM，您的視圖模型以非常有限的方式與視圖進行交互：基本上只是對象，屬性和命令。比較一下，在代碼隱藏的地方，視圖和控件本質上是不可分割的。

再利用

如果你的任何代碼隱藏代碼是可以重複使用，足以值得被公開，就可以取出的代碼隱藏並投入通用類。問題是在那之後留下的是不可重用的。

如果您不想進入MVVM深度潛水，那麼您可以通過關注數據綁定來獲得MVVM的一些好處。在瞭解數據綁定的好處後，您可以重新考慮MVVM的其他好處。

來源

2011-01-07 03:33:14

我們不會做的ViewModel單元測試，

隨着MVVM，它不只是單元測試視圖模型。理想情況下，您的虛擬機應該非常薄，只有視圖需要的屬性。所以，測試虛擬機並不是必須的。

但是，沒有虛擬機，你如何做你的跨層功能/功能測試？在Silverlight中，爲了便於測試，您應該使用命令，而不是在代碼隱藏文件中編寫代碼。這允許您在單元測試時模擬按鈕點擊和其他GUI事件。使用MVVM模式和命令，您可以測試所有C＃代碼（不是xaml），直到UI（轉換器，虛擬機等）。

如果我提供的代碼隱藏，他們還可以提供重用公共方法。

不會詳細說明這是一個糟糕的設計，我想問你，這是如何提供可重複使用性的？如果你創建一個用戶控件，那麼代碼隱藏類是一個控件？你想創建控件的實例並使用它們？這就好像說爲什麼我們需要成員方法，我們可以創建公共靜態方法並訪問它們。我有一個強烈的觀點，如果我們不想使用WPF/Silverlight提供的自動綁定，那麼最好不要使用這些技術。爲了充分利用綁定的全部功能，MVVM是必不可少的。

爲什麼它是鬆散耦合的？

虛擬機是你的觀點的很大一部分。它不是從視圖中分離出來的。正如我所說，你的虛擬機應該儘可能的薄，只有你的視圖需要的公共屬性。您的業務邏輯將與您的視圖（和VM）分離。

來源

2011-01-07 05:16:30

我可以回答我如何使用MVVM模式。 MVVM在以下情況下效果更好：

1如果多個控件綁定在一個屬性中。

MVVM：

<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/> 
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>

我可以快速添加類似的控制或刪除現有的控制。

比較後臺代碼：

public string IsSomePropertyTrue 
{ 
    set 
    { 
     //... 
     text1.Visibility = value; 
     text2.Visibility = value; 
    } 
}

2取而代之的是多轉換器的

公共刷StateColor { 得到 { 如果（this.State == State.Edited & & this.IsPriority）返回新的SolidColorBrush（Color.FromArgb（255，0，255，0））; // ... } }

<sdk:DataGridTemplateColumn.CellTemplate> 
    <DataTemplate> 
     <TextBlock Background="{Binding StateColor}" Text="{Binding State}"/> 
    </DataTemplate> 
</sdk:DataGridTemplateColumn.CellTemplate>

3如象列表框或數據網格控制的項目模型。例如，如果我想用每個項目附近的刪除按鈕創建項目列表，我將創建一個ItemView控件和一個ItemViewModel類。

<ItemsControl ItemsSource="{Binding SomeItems}"> 
    <ItemsControl.ItemTemplate> 
     <DataTemplate> 
      <view:ItemView DataContext="{Binding}"/> 
     </DataTemplate> 
    </ItemsControl.ItemTemplate> 
</ItemsControl>

4複製從一個視圖數據到另一：

public JournalEntryViewModel(SalesOrderViewModel vm) {}

5視圖模型可以繼承CLR類和實現接口（INotifyPropertyChanged的或INotifyDataErrorInfo）。

另外我用MVVM用命令或屬性替換事件。並使用ViewModels強制通過可理解的名稱來調用屬性。

來源

2011-01-07 13:42:46 vorrtex

MVVM中的一個有趣之處是動態自動綁定。想象一下，你的視圖模型有這樣的屬性：bool IsFirstNameVisible，bool IsFirstNameEnabled，string FirstName，double FirstNameWidth等等。

在您的XAML文件中，使用x：Name =「FirstName」定義TextBox並調用您的動態MVVM綁定器。它通過反射檢查你的視圖模型類，查看你定義的屬性，並動態地將它們綁定到具有相同名稱的控件的類似屬性，如果需要的話應用值轉換器。

在這種情況下，您將獲得非常乾淨的XAML，而不需要長達數千米的數據綁定表達式和轉換器。

這就是我的MVVM庫所做的。

來源

2011-01-07 14:19:57

分離Conerns人。關注點分離。

忘記單元測試（我喜歡它，但這不是這裏的東西）。忘記可重用性（你真的重新使用視圖模型嗎？不，我們真的在這裏）。

這是關於分離問題並將代碼和邏輯放在它所屬的位置。整個想法是可維護性;能夠隨着時間的推移而對代碼進行更改，而不會破壞其他內容，也不會將整個事情變成一大堆意大利麪條。

MVVM，正確完成後，可以將您的代碼分離爲有意義的邏輯部分，並可根據應用程序需求的變化輕鬆進行重構和更改。這很容易找到其中什麼是當你需要做出改變。嘗試編寫任何中途複雜的應用程序，然後單獨放置一個月，然後再回來嘗試做出重大改變。合理使用MVVM的適當結構的應用程序在裁員後更容易被挖掘，並且更容易進行更改。

來源

2011-01-10 16:00:13

我是WPF的早期採用者，我可以告訴你是什麼讓我選擇MVVM（並且這或多或少也適用於Silverlight）。對於我正在開發的項目，我必須創建一個允許用戶訂閱系統內通知的屏幕。這是一個3個步驟：

用戶不得不尋找項目，他們想約
通知他們不得不選擇項目，並填寫其他選項有關訂閱
系統有提供摘要並允許用戶確認或編輯訂閱。

第一次實現功能（沒有MVVM）後，我被告知我們需要排除用戶已經訂閱的搜索項。

做出修復後，我被告知我們需要根據選項爲用戶提供預訂的實時預覽。

那時我開始注意到，如果我不必在操作UI時處理這些更改，就可以提取這些更改並使其更容易，因爲我更改了邏輯。我從來沒有故意遵循MVVM，但我意識到我所做的抽象與MVVM模式緊密匹配。

所以這就是我推薦這種模式的原因。它簡化了改變驅動UI的邏輯的任務，將其與UI本身分離。我也建議你暫緩實施它，直到你需要它。使用MVVM有成本，但是它會在更改UI邏輯的成本上攤銷。

來源

2011-01-10 23:11:59

沒有MVVM，你的Silverlight應用程序的代碼很快就會變成無法控制的混亂

來源

2011-11-15 16:45:48 Inga

爲什麼我應該在Silverlight應用程序中使用MVVM？

回答

相關問題