如果我将我的EF 4模型对象（EF4实体）作为我的ViewModel上的属性公开，我是否“打破”MVVM？
我是否必须将每个Model类复制为某种DTO并从ViewModel中公开这些DTO？
我理解让View不知道关于模型的理论价值，但实际情况是（如果我没有通过ViewModel将模型暴露给View）我必须要有一些类具有与要绑定的Model类相同的属性。然后，在ViewModel中，我必须刮掉那些DTO-ish对象的属性来更新适当的EF实体（模型）。
这似乎需要编写和维护许多额外的代码。如果我将实体公开为我的ViewModel上的属性（并绑定到该属性），我仍然可以使用通过绑定到ViewModel属性在ViewModel和启用/禁用状态集中设置其代码/逻辑的命令（即用于保存或删除）。
如果您想知道：“为ViewModel编写一个或两个DTO有什么大不了的？”你的想法太小了。
我有一个包含75个以上SQL表的应用程序（因此有75个以上的EF4实体）。我不喜欢编写和维护75+ DTO的想法。现在我可以使用T4为我的所有实体生成DTO，甚至让它生成部分类，这样我就可以“自定义”这些生成的DTO，而不必丢失自定义项，如果我必须重新生成。 尽管如此，我还是觉得做这一切是“值得的”......而且我还不确定。
想法？
答案 0 :(得分：1)
我们还在模型中使用了大约200个实体来解决这个问题。由于数据绑定直接写回模型，因此ViewModel实际上不再对db实体的这些更改进行控制。目前，我们已经找到了一个解决方案，我们将在下一个重构周期中实施该解决方案。我们还使用T4模板来改善一些EF功能缺乏。所以我们的想法是拥有一个ViewEntity和一个DbEntity。为此，您不必创建/生成另一个DTO类。如果您实例化一个新实体，而不将其添加到ObjectContext，它的行为就像一个简单的DTO。
所以我们的解决方案将是：
下载db实体并将其绑定到上下文（我们使用的是CLR存储过程和T4生成的Materializers）
使用T4生成的Clone（）方法为每个实体创建一个新实体，该实体将公开给视图，该方法返回数据库实体的未绑定版本。
现在，您可以完全控制在视图模型中写回更改或撤消更改，因为数据绑定到视图实体不会影响数据库实体。