WPF编程方法论

时间：2013-01-17 14:35:46

标签： wpf entity-framework mvvm .net-4.5

在WPF上编程我的APP 3个月之后，我第二次想到了我编写应用程序的方式（我知道这可能为时已晚）。在我的APP上，我正在使用我的工具管理的软件的API。我的DAL包含16个类，其中3个是单例。 我在.cs个文件中有一些逻辑，而XAML偏离了它。 我的问题是，我看到很多评论认为用WPF编写的应用程序应该使用MVVM，这将使代码更具可用性和可读性，我可以将我的代码转换为MVVM吗？什么是MVVM的实际含义（不是维基百科或手册定义）？

我也使用SQL查询，我读了一篇关于EF（实体框架）的论文，MVVM和EF可以在同一个项目中共存吗？

我知道我的问题是一个新手问题（我是新手：P）和一个抽象的问题，但我想知道我写的应用程序将是我此时写的最好的：）< / p>

4 个答案:

答案 0 :(得分：118)

MVVM的实际含义是： UI不是数据。数据是数据，UI是UI 。

这意味着您不应该以程序逻辑（通常称为业务逻辑）紧密耦合或依赖于UI组件状态的方式开发应用程序，而是使其依赖于数据项的状态（是它是模型，或视图模型）。

例如，在其他框架（例如winforms）中，如果您的屏幕包含文本框和按钮，则通常会向按钮添加单击事件处理程序，然后从文本框中读取文本。在MVVM中，TextBox的Text属性应绑定到ViewModel中的字符串属性，并且该按钮也应绑定到ViewModel中的Command。

这允许对UI进行抽象（即ViewModel），因此，正如我之前所说，您的应用程序逻辑可能不依赖于UI而是依赖于它的抽象。

这允许UI和逻辑中的大量可伸缩性，并且还允许UI行为的若干方面的可测试性，因为在ViewModel中定义了大部分UI行为。

MVVM还有其他方面，但主要的实现是。

修改

我将为答案的完整性添加一个具体的例子：

1 - 非MVVM WPF：

XAML：

<StackPanel>
   <TextBox x:Name="txtLastName"/>
   <Button Content="Click Me" Click="Button_Click"/>
</StackPanel>

代码背后：

private void Button_Click(object sender, EventArgs e)
{
    //Assuming this is the code behind the window that contains the above XAML.
    var lastname = this.txtLastName.Text; 

    //Here you do some actions with the data obtained from the textbox
}

2 - MVVM WPF：

XAML：

<StackPanel>
   <StackPanel.DataContext>
       <my:MyViewModel/>
   </StackPanel.DataContext>
   <TextBox Text="{Binding LastName}"/>
   <Button Content="Click Me" Command="{Binding MyCommand}"/>
</StackPanel>

视图模型：

public class MyViewModel
{
    public string LastName { get; set; }

    public Command MyCommand { get; set; }

    public MyViewModel()
    {
        // The command receives an action on the constructor,
        // which is the action to execute when the command is invoked.
        MyCommand = new Command(ExecuteMyCommand); 
    }

    private void ExecuteMyCommand()
    {
        //Only for illustration purposes, not really needed.
        var lastname = this.LastName; 

        //Here you do some actions with the data obtained from the textbox
    }
}

正如您在上面的示例中所看到的，ViewModel根本不包含对View的引用。因此，只要{Bindings}保持不变，视图就可以是任何东西。

魔法使它们一起工作的粘合剂是WPF UI元素的DataContext属性，它是将解析所有绑定的对象。

还有其他一些东西，比如ViewModel中的属性更改通知，可以启用双向绑定，但这超出了这个答案的范围。

还要记住，MVVM是一种设计模式，而WPF是一种框架。 MVVM目前也正在应用于其他技术（目前有很多关于网络MVVM的嗡嗡声，有JavaScript和类似的东西）

我建议您阅读其他答案中提到的书籍以及this Tutorial以了解更多WPF特定方面。

答案 1 :(得分：14)

  

我的问题是，我看到很多关于用WPF编写的应用程序的评论   应该使用MVVM，这将使代码更具可用性和可读性，   我可以将我的代码转换为MVVM吗？

不要求您需要使用MVVM模式 - 无。您需要考虑正在构建的应用程序的复杂性以及开发组技能集。一般来说，如果它是一个小型或小型/中型应用程序，那么MVVM 可能过度工程。如果小组的技能/才能不适合分离的演示模式，那么MVVM可能不是一个好的决定。

如果做得好，那么MVVM会为您提供您所了解的各种好处。相反，如果它做错了，那么它可能是一个开发和维护的噩梦 - 绝对不是更具可读性和可用性。从个人经验来看，我认为使用编写糟糕的代码隐藏应用程序而不是基于MVVM编写得不好的应用程序更容易。

当然，您可以将当前的应用程序重写为MVVM模式。只需删除你的代码隐藏并将其放入你的视图模型，辅助类，存储库类，商业逻辑类等等。不要陷入将所有内容放入视图模型的过程中，创建一个MVVM荣耀的代码-behind。

  

我也使用SQL查询，我读了一篇关于EF（实体框架）的论文，   MVVM和EF可以在同一个项目中合并吗？

当然，他们可以。请记住，EF是一种数据访问技术，MVVM是一种设计模式。你可能会在你提到的DAL课程中使用EF。

最后一个想法，如果你决定沿着MVVM路线走，那么你应该考虑使用一个促进它的框架，比如Prism。哦，并为相当多的学习和挫折做好准备。

答案 2 :(得分：2)

这些是我特有的MVVM

1）增加视图的“Blendability”（使用Expression Blend设计视图的能力）。这样就可以将团队中的责任分离出来，这些团队很幸运，有一个设计师和一个程序员......每个人都可以独立于另一个人工作。

2）“Lookless”查看逻辑。视图与在其后面运行的代码无关，使得相同的视图逻辑可以在多个视图中重用，或者可以轻松地重新组织或替换视图。分离“行为”和“风格”之间的关注。

3）没有重复的代码来更新视图。在代码隐藏中，你会看到很多调用“myLabel.Text = newValue”到处都是。使用MVVM，您可以确保通过设置基础属性及其所有视图副作用来适当更新视图。

4）可测试性。由于您的逻辑完全不了解您的视图（没有“myLabel.Text”引用），因此单元测试变得简单。您可以在不涉及其视图的情况下测试ViewModel的行为。这也启用了测试驱动的视图行为开发，使用代码隐藏几乎是不可能的。

其他两种模式在他们所关注的问题上实际上是分开的。你可以将MVVM与MVP和MVC一起使用（大多数好的样本都有这种形式）。

事实上，在我看来，MVP（带被动视图，而不是监督控制器）实际上只是MVVM的一种变体。

答案 3 :(得分：1)

我肯定会使用像DependencyInjection这样的框架来研究Unity。

您的Singleton类可以使用DependencyInjection容器注册并注入其他类的构造函数（例如ViewModels）。其他DAL类也需要定期实例化并注入类中。

DependencyInjection是开发大型企业软件应用程序时最重要的设计模式，适用于客户端和客户端。服务器代码。 MVVM是一个很好的模式，但不会解决与依赖性耦合相关的整体应用程序复杂性问题。

相关问题
最新问题