entity-framework - 将 Entity Framework 实体公开为 ViewModel 上的属性以进行 MVVM 数据绑定(bind)

Question

如果我将我的 EF 4 模型对象(EF4 实体)公开为我的 ViewModel 上的属性，我是否“破坏”了 MVVM ？

我是否必须将每个 Model 类复制为某种 DTO 并从 ViewModel 公开这些 DTO？

我理解让 View “不知道”模型的理论值(value)，但现实是(如果我不通过 ViewModel 将模型暴露给 View )我必须有一些具有相同的类属性作为要绑定(bind)到的模型类。然后，在 ViewModel 中，我必须抓取那些 DTO-ish 对象的属性以更新适当的 EF 实体(模型)。

这似乎需要编写和维护很多额外的代码。如果我将实体作为 ViewModel 上的属性公开(并绑定(bind)到该属性)，我仍然可以使用在 ViewModel 中具有其代码/逻辑并通过绑定(bind)到 ViewModel 属性设置启用/禁用状态的命令(即用于保存或删除)。

如果您想知道:“为您的 ViewModel 编写一两个 DTO 有什么大不了的？”你想的太小了。

我有一个包含 75+ 个 SQL 表(因此有 75+ 个 EF4 实体)的应用程序。我不喜欢编写和维护 75 多个 DTO 的想法。现在我可以使用 T4 为我的所有实体生成 DTO，甚至让它生成部分类，这样我就可以“自定义”这些生成的 DTO，而不会在我必须重新生成时丢失自定义。
不过，我需要觉得做这一切是“值得的”……我还不确定。

想法？

Answer 1

我们也遇到了这个问题，模型中有大约 200 个实体。由于数据绑定(bind)直接写回模型中，因此 ViewModel 实际上无法控制对 db 实体的这些更改。目前，我们已经找到了一个解决方案，我们将在下一个重构周期中实现。我们还使用 T4 模板来改进一些 EF 功能的不足。所以我们的想法是拥有一个 ViewEntity 和一个 DbEntity。为此，您不必创建/生成另一个 DTO 类。如果您实例化一个新实体，而不将它添加到 ObjectContext，它的行为就像一个简单的 DTO。

所以我们的解决方案是:

下载 db 实体并将其绑定(bind)到上下文(我们使用 CLR 存储过程和 T4 生成的 Materializer)

使用 T4 生成的 Clone() 方法为每个实体创建一个新的 View 实体，该实体将公开给 View ，该方法返回 db 实体的未绑定(bind)版本。

现在您可以完全控制在 View 模型中写回更改或撤消更改，因为与 View 实体的数据绑定(bind)不会影响 db 实体。