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