我目前正在研究我第一次真正尝试使用 MVVM,并且一直在阅读各种关于如何最好地实现它的文章。
我当前的想法是有效地使用我的数据模型作为数据传输对象,使它们可序列化并让它们同时存在于客户端和服务器端。
这似乎是一个合乎逻辑的步骤,因为这两种对象类型实际上只是属性 getter 和 setter 的集合,而中间的另一层似乎完全是多余的。
显然,INotifyPropertyChanged 在服务器端无法正常工作会出现问题,因为没有要通信的 ViewModel,但只要我们小心地从服务层中的数据模型构建正确的域模型对象,而不是处理服务器端的数据模型我认为这不应该是一个大问题。
我在阅读中没有找到太多关于这种方法的信息,所以我想知道这是否是一个非常标准的事情,这是否只是假设为在多层环境中执行 MVVM 的事实上的方式?
如果我对事物的想法完全错误,那么对其他方法的想法也会受到赞赏。
您可以使用任何您觉得舒服的模型,是的,您的所有属性都需要 INotifyPropertyChanged 行为。这将如何影响服务层完全取决于您的实现。
我假设您的意思是您认为您绑定到 DTO?
我的看法是,应用程序各层之间存在阻抗不匹配,这是您的
领域模型可能看起来与关系模型类似,但存在细微但至关重要的差异。还有
域模型和 DTO 之间不匹配(对象可能被展平、计算属性等……)。直接绑定到 DTO 很诱人,因为它们可能被设计为具有特定操作所需的内容,但是 DTO 与视图所需的阻抗之间也存在不匹配,以实现预期的结果。这就是视图模型的用武之地。视图模型负责将 DTO 属性代理给视图,负责让视图知道是否存在验证错误,并将命令路由到适当的处理程序(保存、删除等) ,...)。
我倾向于按以下方式进行设置:
// POCO object. Serializable.
public class AddressDto
{
public int Id { get; set; }
public string Street { get; set; }
public string City { get; set; }
public string Country { get; set; }
}
// IDataErrorInfo for validation.
public class AddressViewModel : INotifyPropertyChanged, IDataErrorInfo
{
private readonly AddressDto addressDto;
public AddressViewModel(AddressDto addressDto)
{
this.addressDto = addressDto;
}
public int Id { /* get and set for property changed event and update dto */ }
public string Street { /* get and set for property changed event and update dto */ }
public string City { /* get and set for property changed event and update dto */ }
public string Country { /* get and set for property changed event and update dto */ }
...
// IDataErrorInfo implementation
}
public class EditAddressViewModel : INotifyPropertyChanged
{
public AddressViewModel Address { /* get and set for property changed event */ }
public ICommand Save { /* setup command */ }
public ICommand Cancel { /* setup command */ }
private void Save()
{
}
private void Cancel()
{
}
}
然后,您的 EditAddressView 将绑定到 EditAddressViewModel。基本上,规则是所有 UI 行为都应该用视图模型来表达。
是的,这确实意味着额外的工作,但是您可以采取一些措施来简化事情(代码生成等)。我实际上正在开发一个库,旨在使用流畅的 api 简化整个 MVVM 流程。检查一下:http://fluidviewmodel.codeplex.com/ http://fluentviewmodel.codeplex.com/
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)