ASP.NET MVC - 视图模型、领域模型和数据模型

Question

我在最新的ASP.NET MVC 3项目中使用了实体框架（Entity Framework）。由于它是数据库优先（DB first），所以实体框架生成了数据库模型。在我的服务（业务）层中，我使用Scaffold（MvcScaffolding）生成服务方法、视图和控制器。Scaffolding还生成了领域模型。在将这些模型绑定到视图时，我使用视图模型。

简而言之，我最终使用了三种类型的模型。这样做可以吗？视图模型保存在表示层，领域模型保存在业务层，数据模型保存在存储库层。

请让我知道您的想法。

- w3dev

Answer 1

听起来不错，确实有几个好处。

1. 您可以从头开始重新创建数据库模型，而不会影响域模型，当然，除了它们的映射方式。一些人认为这两者可以合并为一个，但这在很大程度上取决于您的设置。

2. 分离的视图模型将允许您更自由地更改和创建新的视图模型以适应您的视图。 它还有助于防止延迟加载代理等。

许多人也会有一组Dto对象。 如果您有超过一个UI（例如Windows服务），则这些对象非常有用，因为它们是一组用于缓存的对象。

Automapper非常受欢迎，可以简化如此多的模型映射的痛苦。

- dove

---

谢谢。那很有道理。顺便问一下，如果我的表现层和业务层之间有一个门面层，我应该添加另一组DTO吗？还是视图模型可以作为传递数据的DTO来在表现层和业务层之间传递数据？（虽然这需要我将我的视图模型添加到业务层中） - w3dev

你不应该将你的视图模型用作数据传输对象（DTO）。如果你需要 DTO，请创建它们，但仅在需要时创建。 - dove

由于我有一个外观层，所以我想确保所有调用都只通过外观层进行。在这种情况下，我认为我最终会创建大量的DTO。但是，再次确认 - 这样做可以吗？ - w3dev

这很正常，DTO的数量大于领域模型的数量，但少于视图模型的数量，并不罕见。 - dove

Answer 2

在各个层级之间存在差异是很好的。如果你所做的只是将一个层模型中的数据直接放到另一个层模型中而没有任何转换和处理，那么你可以删除冗余模型。通常情况下，领域模型变得多余了。

由于需要能够从数据库重新创建数据库模型而不更改视图，因此应创建独立的视图模型和数据库模型。

- Kirill Bestemyanov

---

+1，这就是正确的理念。只有在需要时才去做它。 - Sedat Kapanoglu

谢谢。但是我可能还需要业务模型来将数据从表示层传递到业务层，然后映射到数据模型。我有什么遗漏吗？ - w3dev

据我所知，不，你不是。 - Kirill Bestemyanov