我们正在我们的团队中,研究将WPF与Prism一起使用的可能性。
我们当前的解决方案是使用Windows Forms构建的,因此在满意地实现此体系结构迁移的目标之前,必须考虑和研究许多因素。
MVVM模式是与这些因素相关的新功能之一。这种模式使用了与我们团队目前所知的那种完全不同的概念。
我们正在阅读和学习很多东西,我们无法确定它的用途(纯粹)是否真的有效用于我们的目的:我们将创建一个具有大量窗口的应用程序使用CRUD(创建,读取,更新和删除)模型。例如:客户注册,产品注册等。 我们认为使用此模式可能会导致模型定义期间的返工,必须在ViewModels定义期间重写。
我想知道是否有人有任何经验报告或提示可以指导我们使用这些技术。
答案 0 :(得分:12)
如果您正在使用WPF,请务必使用MVVM设计模式。它使生活变得更加简单,并且将来的维护变得容易。
关于你的评论
我们认为使用此模式可能会导致模型中的返工 定义,必须在ViewModel期间重写 定义
有两种方法可以处理MVVM中的Models / ViewModel。 “MVVM-purist”方法是从ViewModel公开Model的属性,在这种情况下,是的,你将复制一些代码。更实用的方法是从ViewModel公开整个Model。两种方式都是可以接受的,尽管我建议使用第二种方式,除非你有一个非常大的项目,其中有不同的人/团队在模型和ViewModel层上工作。
MVVM Purist:
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
时RegionManager
MenuRegion
NavigationRegion
参数更改。
我不太喜欢Prism的唯一内容是他们的ContentRegion
。我觉得让View控制应用程序流程太多,而不是ViewModels。我也看到它经常被误用于导航,而且经常变成一团糟。我仍然使用它来定义我的应用程序布局(例如,{{1}},{{1}},{{1}}),但除此之外,我使用我的ViewModel来满足所有导航需求。
所以最终,我会说它去吧!我喜欢使用WPF,我觉得你不应该在没有MVVM设计模式的情况下使用WPF。 Prism也是一个很棒的库,可以提供我认为在每个MVVM应用程序中都需要的一些缺少的功能。