为什么我应该在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？

回答

相关问题