ASP.NET MVC-视图模型模式

您在此处已命名三件事： 网站统计 动态菜单 可能来自数据库的任何其他东西 第三点是陷阱。仅仅是因为您的数据库中存在某些内容，并不意味着它就属于您的域模型。 导航可能基于数据库。它也可能位于站点地图中或硬编码到应用程序中。它实际上不是应用程序数据，而是应用程序配置。如果您将其存储在应用程序数据库中，那就可以了（嗯，不是真的），但这不是模型本身的一部分。 同样，网站统计信息通常存储在数据库中，但存储在其他数据库中，特别是分析数据库中（很多人只是将其“外包”给Google）。同样，它们是一种数据，但不是您的模型。 如果您希望应用程序有意义，则需要在概念上将这些问题分开。导航在您的母版页/布局中完成，包括使之正常工作所需的任何动态代码。这是纯粹的视图逻辑-不要让它泄漏到您的模型中。完全可以，通常最好使用ViewData / ViewBag来解决与当前正在使用的实际功能有关的问题。 现在，假设还有其他类型的视图数据实际上是应用程序数据：原则上说视图应该直接连接到模型是正确的-毕竟这就是“ MVC”的含义-但实际上，这只是对构思错误的“规范数据模型”想法的重新实现。域和表示是独立的关注点，因此，它们暗示着不同的上下文模型-在后一种情况下，这就是视图模型。 当我刚开始进行MVC工作时，我也不愿使用视图模型。但是当我习惯了这个想法之后，我意识到这确实是唯一可行的解​​决方案-尤其是当您的“模型”主要是数据库本身的一个薄包装时。视图和数据以不同的方式和不同的速率变化；如果您不想担心持续不断的错误和回归，那么您需要在两者之间保持一定的隔离。建立一个映射层，并称之为一天。 在这一点上，我已经为每个视图创建了一个不同的视图模型，无论我是否需要它。刚开始时，它可能只是模型类的副本，但这意味着我可以随时以任何方式对其进行调整，而不必搞砸基础模型，反之亦然。正如电视所说，初始视图模型很容易使用AutoMapper生成，可能会花费您30秒钟的时间。 仅使用视图模型，并希望最终这些工具支持视图模型自动生成。     

我从未将实体类直接用作视图模型。我总是为包含该视图数据的每个视图创建特定于视图的模型。我已经开始使用AutoMapper在视图模型和实体模型之间进行映射。我通过ModelMapper类进行了调解，该类具有用于处理标准映射（仅调用自动映射器）的“ 0”方法和用于自定义映射的专用映射方法，尤其是支持从视图模型创建和更新实体。     

如果您创建用于编辑员工的页面但还显示了您提到的内容（站点统计信息/菜单），为什么不将它们放在局部视图或布局文件中？