我只使用 MVC 框架（ASP.NET MVC2/3/Razor）几个月了，我真的很喜欢它，但是我很难弄清楚视图模型的标准。 在我的项目中，我有一个模型文件夹（包含我的数据模型 - Linq DBML，存储库[ies]，扩展方法）和一个模型/视图模型文件夹。 我的视图模型通常是可重用的类，通常只包含 LINQ 对象的简单 get/set 属性或我需要为特定视图访问的对象集合。
现在我遇到的问题是弄清楚何时创建视图模型。 我的目标是尽可能频繁地使用 LINQ 对象作为视图模型，尤其是当它是"编辑"操作时。 我的问题是，如果我有其他可能只想用于显示目的的数据怎么办？ 我不喜欢使用 ViewData/ViewBag 集合，因为访问这些集合的成员需要了解集合项的键（设计师/前端人员不容易"猜测"）。 我也不喜欢为每个视图创建一个 ViewModel 的想法，因为它似乎是不必要的混乱代码。
例如，假设我有一个员工的数据模型，我想显示一些与该员工无关的信息 - 例如，站点统计信息、动态菜单以及您能想到的任何其他可能来自数据库的信息。 我应该传递什么模型/员工/编辑操作？ Employee 对象与一堆 ViewData[] 用于其余部分，还是自定义 EmployeeView？
有金本位吗？ 我错过了什么？ 你做了什么不同的事情，我应该研究一下？ 提前感谢！
我从不直接将实体类用作视图模型。 我总是为每个视图创建一个特定于视图的模型，其中包含该视图的数据。 我开始使用自动映射器在视图模型和实体模型之间进行映射。我通过一个 ModelMapper 类来调解这一点，该类具有用于处理标准映射（仅调用自动映射器）的ToViewModel<TEntity,TViewModel>()方法和用于自定义映射的专用映射方法，尤其是支持从视图模型创建和更新实体。
你在这里命名了三件事：
- 网站统计
- 动态菜单
- 其他任何可能来自数据库的内容
第三点是一个陷阱;仅仅因为数据库中有某些东西，并不意味着它是你的领域模型的一部分。
导航可能基于数据库。 它也可能位于站点地图中或硬编码到应用程序中。 它实际上不是应用程序数据，而是应用程序配置。如果你把它存储在应用程序数据库中，那没关系（嗯，不是真的），但它不是模型本身的一部分。
同样，网站统计信息通常存储在数据库中，但它们存储在不同的数据库中，特别是分析数据库（许多人只是将其"外包"给Google）。 所以再说一次，它们是一种数据，但它们不是你的模型。
如果希望应用程序有意义，则需要在概念级别分离这些问题。 导航在母版页/布局中完成，包括使其工作所需的任何动态代码。 这是纯粹的视图逻辑 - 不要让它泄漏到您的模型中。 这是完全可以的，通常最好使用 ViewData/ViewBag 来解决与当前正在使用的实际功能相关的问题。
现在，假设有其他类型的视图数据实际上是应用程序数据：原则上视图应该直接连接到模型 - 毕竟这就是"MVC"的含义 - 但在实践中，它只是对考虑不周的"规范数据模型"想法的重新实现。 域和表示是单独的关注点，因此，意味着不同的上下文模型 - 在后一种情况下，这是一个视图模型。
当我第一次开始做MVC工作时，我也不愿意使用视图模型。 但是在我更习惯了这个想法之后，我意识到它确实是唯一站得住脚的解决方案 - 特别是当你的"模型"主要是数据库本身的薄包装器时。 视图和数据以不同的方式和不同的速率变化;如果您不想担心源源不断的错误和回归，那么您需要在两者之间进行一些绝缘。 构建一个地图图层并调用它一天。
在这一点上，我已经为每个视图创建了一个不同的视图模型，无论我认为我是否需要它。 一开始，它可能只不过是一个模型类的复本，但这意味着我可以随时以任何方式调整它，而不必搞砸底层模型 - 反之亦然。 正如电视所说，使用AutoMapper生成初始视图模型非常容易，并且可能会占用您30秒的时间。
只需使用视图模型，并希望最终工具支持视图模型自动生成。
如果您创建用于编辑员工的页面，但您还显示您提到的内容（站点统计信息/菜单），为什么不将它们放在部分视图或布局文件中？