2

在开始之前，我想说我知道 ViewModel 是什么，以及它的目的是什么，但是这种情况使它变得多余.. 请继续阅读 :)

我正在开发一个 ASP.NET MVC4 应用程序，并且在 PagedList、Domain Entities 和 ViewModels 方面遇到了一些令人头疼的问题。

基本上，PagedList.MVC 插件不能很好地与 AutoMapper 配合使用，我必须做一些额外的工作才能让它按我的意愿工作。

但后来我想，当需要相关域实体上的所有属性时，我是否还需要一个 ViewModel 类？

当视图需要域实体上的每个属性时，视图模型有什么好处？

4

2 回答 2

2

这可能是一个见仁见智的问题，我喜欢使用具有以下好处的视图模型（和 DTO）：

  • 我确定视图所需的所有数据都已加载，而不是代理等。
  • 如果制作正确，DTO 会提供一个更小的图表来存储在缓存中（可能不适用于您的设置）
  • 它允许我的视图模型与域对象有很大的不同，通常它们是复合的并且非常扁平化并且可以自由地改变它们而不影响我的应用程序的任何其他部分。

现在为了应对上述情况，许多人会，您可以直接使用您的域对象。如果您发现您的视图模型只是您的域的一对一相似之处并且您在上面看不到任何好处，我可能也会推荐这个。

像往常一样，这取决于您的设置

  • 你的团队
  • 是什么让你富有成效
  • 使用的工具，如果有的话，使用 ORM
  • 项目规模和持续时间
  • 经验
  • 等等等等等等
于 2014-02-20T14:24:36.117 回答
1

我只想为小型项目添加它，只需拥有自己的 ViewModel 并使用它就可以了。您可以稍后在需要时将实体分开。

许多开发人员在不权衡利弊的情况下添加新层，后来他们开始注意到滞后，然后产生怀疑。MVC 本身已经是一个关注点分离。

拥有一个单独的 DomainEntity 解决了一个不同的问题，即 UI 不再将 1 对 1 映射到实体，请考虑以下问题。

Version 1
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
User.PositionTitle  | User.PositionTitle

该示例演示了域和表示不再是一对一的映射。将来，您可能会进行域修改，例如：

Version 2
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
Position.Title      | User.PositionTitle

根据上面的示例（版本 2），请注意演示文稿没有被修改。具有分离的域模型提高了界面稳定性。它甚至可以降低重构场景的更改成本。

ViewModel 的优势

ViewModel 的美妙之处在于它将您的领域与演示文稿分离，这种好处在用于大型项目时更为明显，其中不同的开发人员处理系统的不同部分（例如单独的 GUI 团队）

一个小的改变需要改变许多类。

这是解耦实体的缺点之一，它会产生代码重复。额外的编码需要付出巨大的代价，而且好处必须是显而易见的才值得。

于 2014-02-21T05:44:46.183 回答