有没有理由将POCO变成Model对象？

Question

如果我从EntityFramework生成POCO对象,并使用这些对象进出WCF服务器,是否有任何理由为Views&ViewModels创建客户端模型而不是直接使用POCO？

我所看到的几乎所有MVVM示例都直接绑定到从WCF服务返回的对象.这是好习惯吗？是否存在可以将POCO实际映射到模型并使Views/ViewModel与Model对象而不是POCO一起工作的参数？

我能想到的主要原因是验证,但由于EF POCO是部分类,因此可以扩展它们以包括验证.

编辑

到目前为止,大多数答案都是INotifyPropertyChanged构建单独模型的主要原因.如果您使用自我跟踪实体而不是已包含的POCO,您的答案是否会改变INotifyPropertyChanged？STE也是部分类,可以扩展到包括验证.

Answer 1

验证是不直接绑定到POCO的主要原因.此外,如果POCO尚未实现INotifyPropertyChanged和其他必需的接口,那么在WPF端使用对象的经验可能不太理想,并且实现ViewModel来包装它是有意义的.

提供ViewModel来包装POCO允许您将逻辑封装到ICommand实现中以及干净地实现所需的接口.

Answer 2

我对里德只是略微不同意(这是一个不寻常的情况).我不会实现ViewModel来包装POCO.我将实现一个Model类来包装POCO并通过Service层将模型公开给ViewModel.

ViewModel的主要工作是将模型数据适当地呈现给View并对其请求作出反应.我正在为此工作的架构看起来像这样:

• 每个View 1个ViewModel
• ViewModel调用数据服务层对象来检索模型实例(不要与WCF服务混淆)
• 数据服务层向后端发出适当的CRUD请求(这为Silverlight使用WCF,RIA或RESTful服务,但可以直接为WPF使用ADO.NET或EF).
• 数据服务使用返回的POCO来创建Model对象.
• 模型对象包装POCO对象并实现INotifyPropertyChanged.模型对象强制执行业务规则.

我仍在研究细节,但我将在不久的将来发布一些更具体的内容.