如果我从EntityFramework生成POCO对象，并使用这些对象进出WCF服务器，是否有任何理由为Views＆ViewModels创建客户端模型而不是直接使用POCO？
我所看到的几乎所有MVVM示例都直接绑定到从WCF服务返回的对象 . 这是好习惯吗？是否存在可以将POCO实际映射到模型并使Views / ViewModel与Model对象而不是POCO一起工作的参数？
我能想到的主要原因是验证，但由于EF POCO是部分类，因此可以扩展它们以包括验证 .
EDIT
到目前为止，大多数答案都将 INotifyPropertyChanged 作为构建单独模型的主要原因 . 如果您使用自我跟踪实体而不是已包含 INotifyPropertyChanged 的POCO，您的答案是否会改变？ STE也是部分类，可以扩展到包括验证 .
5 回答
验证是不直接绑定到POCO的主要原因 . 此外，如果POCO尚未实现
INotifyPropertyChanged和其他必需的接口，那么在WPF端使用该对象的经验可能不太理想，并且实现ViewModel来包装它是有意义的 .提供ViewModel来包装POCO允许您将逻辑封装到
ICommand实现中，以及干净地实现所需的接口 .我对里德只是略微不同意（这是一个不寻常的情况） . 我不会实现ViewModel来包装POCO . 我将实现一个Model类来包装POCO并通过Service层将模型公开给ViewModel .
ViewModel的主要工作是将模型数据适当地呈现给View并对其请求作出反应 . 我正在为此工作的架构看起来像这样：
1每个视图的ViewModel
ViewModel调用数据服务层对象来检索模型实例（不要与WCF服务混淆）
数据服务层向后端发出适当的CRUD请求（这对Silverlight使用WCF，RIA或RESTful服务，但可以直接为WPF使用ADO.NET或EF） .
数据服务使用返回的POCO创建Model对象 .
模型对象包装POCO对象并实现INotifyPropertyChanged . 模型对象强制执行业务规则 .
我仍在研究细节，但我将在不久的将来发布一些更具体的内容 .
我的模型接受一个WCF对象，该对象公开了我希望在我的ViewModel中使用的那些属性 . 然后我可以根据需要扩展对象 . 我的属性指向WCF对象's property and when I have to send the object back to the WCF service, I don' t必须做更多的工作 . 模型继承 INotifyPropertyChanged 和 INotifyDataErrorInfo ，DTO（此处称为POCO）不具备 . 您的业务逻辑/验证存在于Silverlight应用程序中，而不存在于WCF服务中 .
视图绑定到ViewModel，后者具有Model（或可观察的模型集合） . 模型有一个WFCObject，它是一个DTO（这里称为POCO） . 我使用我的ViewModel与服务进行通信，MVVM Light让模型与服务/提供者进行通信 - 这是我不喜欢的 .
如果你想做简单的CRUD或想要快速制作东西，请绑定到EF POCO .
否则，与用户界面相比，您的服务器端模型往往与数据库密切相关，数据库的变化非常缓慢 . 对于不那么琐碎的用户界面，你会发现自己只是为了使你的数据库模型适合用户界面而设置越来越多的kludges（或者更糟糕的是，这更糟糕） .
此外，还存在性能问题（例如，您希望在UI时只需要几个属性来传输整个实体吗？）和维护问题（例如，如果您希望验证高级客户的订单与普通客户的订单完全不同） .
另见http://ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-approach-will-fail.aspx
Rachel的POCO只是由EF生成并用于传输（DTO）的愚蠢对象 . 因此，他们不应该让其他东西混乱他们的领域 . 这是设计代码的一种非常好的方法，因为它将任何客户端要求与服务器端的要求分离 . 这就是MVVM存在的原因 - 扩展包含这些问题的MVC模型 .
只要您不直接修改它们，就没有理由不能在视图中绑定它们 . 您可以通过添加部分类来为它们添加功能，但我不会甚至那样做 . 在这种情况下，您应该遵循MVVM设计租户并将其分离为满足客户需求的模型对象 . 一旦您连接INotifyPropertyChanged事件以通知您的视图，这将是非常自动化的 .