我想知道为什么我们应该使用 MVVM 来实现 Silverlight 应用程序。它有什么优势？
我们不为 ViewModel 做单元测试，所以我想要其他原因。
以下是我对人们通常说的一些优势的问题：
1.松耦合：当我们使用 MVVM 时，一个视图依赖于 ViewModel 而不是一个视图，为什么它是松耦合的？
2.如果我在代码隐藏中提供公共方法，它们也可以提供可重用性。
【问题讨论】：
标签： silverlight mvvm
我认为这是可用的最佳资源之一，以防您想使用和对比 MVVM 与任何其他模式或无模式的使用情况。
http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/
【讨论】：
好吧，视图模型的单元可测试性是一个显着的优势，所以你会错过这个好处。关于其他两个：
松散耦合
是的，视图确实依赖于视图模型。它们必须以某种方式连接才能完成应用程序的功能。因此，它们不能解耦。唯一的选择是紧耦合或松耦合或介于两者之间。使用 MVVM，您的视图模型以非常有限的方式与您的视图交互：基本上只是对象、属性和命令。将此与在代码隐藏中执行所有操作进行比较，其中视图及其控件本质上是不可分割的。
重复使用
如果您的代码隐藏中的任何代码可重用足以值得公开，则可以将其从代码隐藏中取出并放入通用类中。问题是在那之后剩下的东西是不可重复使用的。
如果您不想深入了解 MVVM，那么您可以通过专注于数据绑定来获得 MVVM 的一些好处。在了解数据绑定的好处之后，您可以重新考虑 MVVM 的其他好处。
【讨论】：
我们不对 ViewModel 进行单元测试，
使用 MVVM，它不仅仅是对 ViewModel 进行单元测试。理想情况下，您的 VM 应该非常薄，并且只有视图所需的属性。因此，实际上没有必要测试 VM。
但是，如果没有虚拟机，您如何跨层进行特性/功能测试？在 Silverlight 中，为了方便测试，您应该使用命令，而不是在代码隐藏文件中编写代码。这允许您在单元测试时模拟按钮单击和其他 GUI 事件。使用 MVVM 模式和命令，您可以测试所有 C# 代码（不是 xaml），直到 UI（转换器、VM 等）。
如果我在一个 代码隐藏，他们还可以提供 可重用性。
不详细说明这是一个糟糕的设计，我想问你，这如何提供可重用性？如果创建用户控件，那么代码隐藏类是控件吗？您想创建控件的实例并使用它们吗？这就像说为什么我们需要成员方法，我们可以创建公共静态方法并访问它们。我有一个强烈的意见，如果我们不想使用 WPF/Silverlight 提供的自动绑定，那么最好不要使用这些技术。而要利用绑定的全部功能，MVVM 是必不可少的。
为什么它是松耦合的？
VM 是您观点的重要组成部分。它没有与视图分离。正如我所说，你的虚拟机应该尽可能的薄，只有你的视图需要的公共属性。您的业务逻辑将与您的视图（和虚拟机）分离。
【讨论】：
我可以回答我如何使用 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 代替多路转换器
公共画笔状态颜色 { 得到 { if (this.State == State.Edited && this.IsPriority) return new SolidColorBrush(Color.FromArgb(255, 0, 255, 0)); //... } }
<sdk:DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<TextBlock Background="{Binding StateColor}" Text="{Binding State}"/>
</DataTemplate>
</sdk:DataGridTemplateColumn.CellTemplate>
3 作为 ListBox 或 DataGrid 等控件中的项模型。例如，如果我想创建一个项目列表，每个项目附近都有一个删除按钮，我将创建一个 ItemView 控件和一个 ItemViewModel 类。
<ItemsControl ItemsSource="{Binding SomeItems}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<view:ItemView DataContext="{Binding}"/>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
4 将数据从一个视图复制到另一个视图：
public JournalEntryViewModel(SalesOrderViewModel vm) {}
5 ViewModel 可以继承 CLR 类并实现接口（INotifyPropertyChanged 或 INotifyDataErrorInfo）。
我还使用 MVVM 用命令或属性替换事件。并且使用 ViewModel 会强制通过可理解的名称调用属性。
【讨论】：
MVVM 中另一个有趣的地方是动态自动绑定。
想象一下，您的视图模型具有如下属性：bool IsFirstNameVisible、bool IsFirstNameEnabled、字符串 FirstName、double FirstNameWidth 等。
在您的 XAML 文件中，您使用 x:Name = "FirstName" 定义 TextBox 并调用您的动态 MVVM-binder。它通过反射检查您的视图模型类，查看您定义的属性，并将它们动态绑定到具有相同名称的控件的相似属性，并在需要时应用值转换器。
在这种情况下，您将获得非常干净的 XAML，没有千米长的数据绑定表达式和转换器。
这就是我的 MVVM 库所做的。
【讨论】：
Conerns 人的分离。关注点分离。
忘记单元测试（我喜欢它；但这不是这里的事情）。忘记可重用性（你真的重用视图模型吗？不，让我们在这里真实一点）。
这是关于关注点分离并将代码和逻辑放在它所属的位置。整个想法是可维护性；能够随着时间的推移对代码进行更改，而不会破坏其他东西，也不会把整个东西变成一大堆意大利面条。
MVVM 处理得当，可以将您的代码分成有意义的逻辑部分，并允许在应用程序需求变化时轻松重构和更改。当您需要进行更改时，更容易找到在哪里。尝试编写任何中途复杂的应用程序，然后将其放置一个月，然后再回来尝试进行重大更改。合理使用 MVVM 的结构合理的应用程序在停工后更容易理解，并且更容易进行更改。
【讨论】：
我是 WPF 的早期采用者，我可以告诉您是什么让我选择了 MVVM（这或多或少也适用于 Silverlight）。对于我正在进行的项目，我必须创建一个屏幕，允许用户订阅系统内的通知。这是一个 3 步过程：
在第一次实现该功能后（没有 MVVM），我被告知我们需要从用户已经订阅的搜索项目中排除。
完成该修复后，我被告知我们需要根据选项为用户提供订阅的实时预览。
到那时，我开始注意到，如果我在更改逻辑时不必处理 UI 操作，则可以提取其中一些更改并使其变得更容易。我从来没有故意遵循 MVVM，但我意识到我所做的抽象与 MVVM 模式非常匹配。
所以这就是我推荐这种模式的原因。它通过将 UI 与 UI 本身分离，简化了更改驱动 UI 的逻辑的任务。我还建议您推迟实施它，直到您需要它。使用 MVVM 是有成本的，但它会在更改 UI 逻辑的成本中摊销。
【讨论】：
没有 MVVM，您的 Silverlight 应用程序代码很快就会变得一团糟
【讨论】：