1

假设有一个 PIModel（即个人信息模型）和一个 ViewModel（包含来自 PIModel 和其他的一些信息）。

public PIModel
{
    private string firstName;
    public string FirstName { get; set; }

    private string lastName;
    public string LastName { get; set; }

    ... // other
}

FirstName 和 LastName 属性需要绑定到 View，所以我有两个问题：

  • ViewModel 是否具有对 PIModel 实例的属性引用？
  • 如果有，ViewModel 是否具有对 PIModel.FirstName 和 PIModel.LastName 的属性引用？

我了解到INotifyPropertyChanged不建议在模型中实施。

4

2 回答 2

2

在实践 MVVM 几年之后，我会稍微了解一下答案，即使它不是 100% 符合 MSDN 的。

我强烈同意这个建议：不要在模型中实现 INotifyPropertyChanged。

我会解释为什么：如果你的模型只是属性和 INotifyPropertyChanged，那么它在责任方面的作用是什么？（想想单一责任原则： http ://en.wikipedia.org/wiki/Single_responsibility_principle ）

举个例子：如果你在 PIModel 中使用 INotifyPropertyChanged，那么 PIModel 的作用就是将你的数据呈现给你的视图。顺便问一下，ViewModel 在 MSDN 定义中的作用是什么？你明白了：将你的数据呈现给你的视图。

所以最后，如果你同时使用 Model 和 ViewModel 来呈现你的数据，每个组件的作用就会变得模糊，你会有一些想法，比如“好吧，我觉得这里我什至不需要 ViewModel”。数据呈现职责将设置在不同的概念类中。

在我看来，如果你有这种想法，你只需要 ViewModel（但可能是一个更大的 ViewModel，包含超出其他 PIViewModel）。不要构建贫血模型（只有属性而完全没有责任的模型），因为它会使您的代码复杂化并且没有任何价值。

仅当您向对象添加一些其他责任时才使用模型，并且不显示责任（因为它属于 ViewModel），而是显示真正的业务责任。

因此，如果大部分数据是从服务器获取的，并且大部分业务责任在服务器上，那么我在您的客户端应用程序中主要看到 ViewModel 是合乎逻辑的。

希望能帮助到你。

于 2013-09-12T06:59:37.377 回答
1

如果您的模型是自我通知的，则没有问题。您可以INotifyPropertyChanged实现您的模型。这是 msdn 文章，它将阐明您对模型实现的所有疑问以及如果您的模型未实现 INPC 的解决方法。

http://msdn.microsoft.com/en-us/library/gg405484%28PandP.40%29.aspx

因此，如果您的模型不属于您可以实现的类别INotifyPropertyChanged（例如数据库自动生成的实体），那么您将不得不在 VM 中的模型属性上编写包装器属性。

但坦率地说，如果你可以实现 INPC，你应该这样做，因为它可以避免不必要的代码重复和维护。

于 2013-09-12T02:22:32.577 回答