使用WPF,MVVM和Prism构建应用程序

Question

我们在我们的团队中,研究使用WPF和Prism的可能性.

我们当前的解决方案是使用Windows Forms构建的,因此在满意地实现此体系结构迁移的目标之前,必须考虑和研究许多因素.

MVVM模式是与这些因素相关的新功能之一.这种模式使用了我们团队目前所知道的完全不同的概念.

我们正在阅读和学习很多东西,我们无法确定它的用途(纯粹)是否真的有效用于我们的目的:我们将创建一个具有大量窗口的应用程序将使用CRUD (创建,读取,更新和删除)模型.例如:客户注册,产品注册等.我们认为使用此模式可能会导致模型定义期间的返工,必须在ViewModels定义期间重写.

我想知道是否有人有任何经验报告或提示可以指导我们使用这些技术.

Answer 1

如果您正在使用WPF,请务必使用MVVM设计模式.它使生活变得更加简单,并且将来的维护变得容易.

关于你的评论

我们认为使用此模式可能会导致模型定义期间的返工,必须在ViewModels定义期间重写.

有两种方法可以处理MVVM中的Models/ViewModel."MVVM-purist"方法是从ViewModel公开Model的属性,在这种情况下,是的,你将复制一些代码.更实用的方法是从ViewModel公开整个Model.两种方式都是可以接受的,尽管我建议使用第二种方式,除非你有一个非常大的项目,其中有单独的人/团队在模型和ViewModel层上工作.

MVVM纯粹主义者:

public class CustomerViewModel
{
    private Customer _customer;

    public string Name 
    {
        get
        {
            return _customer.Name;
        }
        set
        {
            if (value != _customer.Name)
            {
                _customer.Name = value;
                RaisePropertyChanged("Name");
            }
        }
    }
}

<TextBlock Text="{Binding Name}" />

更实用的方法:

public class CustomerViewModel
{
    private Customer _customer;

    public Customer Customer
    {
        get
        {
            return _customer;
        }
        set
        {
            if (value != _customer)
            {
                _customer= value;
                RaisePropertyChanged("Customer");
            }
        }
    }
}

<TextBlock Text="{Binding Customer.Name}" />

关于棱镜,我认为这是一个很棒的图书馆.我更喜欢他们NotificationObject和EventAggregator我自己,并且喜欢DelegateCommand一旦我习惯了它不会CanExecuteChanged在CanExecute参数改变时自动提升它.

Prism我唯一不喜欢的是他们的RegionManager.我觉得让View控制应用程序流程太多,而不是ViewModels.我也看到它经常被误用于导航,而且经常变成一团糟.我还用它来定义我的应用程序布局(例如MenuRegion,NavigationRegion,ContentRegion),但除此之外,我用我的ViewModel所有的导航需求.

所以最终,我会说它去吧!我喜欢使用WPF,我觉得你不应该在没有MVVM设计模式的情况下使用WPF.Prism也是一个很棒的库,可以提供我认为在每个MVVM应用程序中都需要的一些缺少的功能.