ASP MVC 3：ViewModels 中的依赖注入是个好主意吗？答案

【问题标题】：ASP MVC 3: Is dependency injection in ViewModels a good idea?ASP MVC 3：ViewModels 中的依赖注入是个好主意吗？
【发布时间】：2012-07-31 12:49:06
【问题描述】：

我正面临一个 mvc 3 应用程序的设计问题。我有一个具有类别列表的视图模型 ProductCreateModel。

现在我在控制器中设置类别列表，但我想在 ProductCreateModel 构造函数中检测数据源是否是个好主意。

你认为视图模型应该是胖模型，也知道从数据源读取依赖数据吗？ ...或者这是控制器的事情？

【问题讨论】：

标签： asp.net-mvc asp.net-mvc-3 design-patterns

【解决方案1】：

我更喜欢对数据层一无所知的纤薄视图模型。它们更容易管理（根据我的经验）。

【讨论】：

【解决方案2】：

我认为视图模型应该是轻型模型，它们读取相关数据的唯一方法应该是“父”对象上的属性，即它们实际包装的模型。

大多数时候，我的视图模型只是具有属性的类，所有逻辑都在控制器或服务类中（如果我们说的是很多逻辑，否则这些逻辑会放在控制器中）。这一切都是为了更容易测试。

【讨论】：

只是想知道，您是否在控制器的操作中实例化了一个新的视图模型类？然后从服务中一一设置每个属性，例如，在操作中？您是否也使用接口抽象视图模型？非常感谢
通常我会在action方法中实例化一个viewmodel类。根据视图模型与实际数据对象的相似程度，您可以使用自动映射器。我通常创建一个 ToViewmodel 扩展方法，并在需要将我的数据对象“转换”为视图模型时使用它。我通常从不在视图模型上使用接口。如果有意义的话，我可能会创建一个抽象超类（几个视图模型共享大多数属性）。

【解决方案3】：

当我学习 MVC 时，我被告知“经验法则”是 Skinny Controllers、Fat Models、Dumb Views。许多 MVC 开发人员犯的一个错误是胖控制器（太多逻辑）、瘦模型（基本上是用于保存数据的 POCO 类）和智能视图（一堆带有 If this、Else that 等的 Razor 语法）

多年来，我一直坚持使用 Skinny Controllers、Fat Models、Dumb 视图方法，它对我来说效果很好。现在，考虑到这与模型而不是视图模型有关。通常你的模型应该在一个完全不同的层（即项目或文件夹）。另一方面，ViewModel 应该相当简单。这使它们更容易测试，并且更可重用。如果您发现需要某种服务、repo 或其他依赖项来构建您的 ViewModel，那么您可能应该将该逻辑抽象到某种 Composer 类中。过去，如果需要，我使用了一个实现 IViewModelManager 的 ViewModelManager 来组合我的 ViewModel。通过这种方式，您可以将 IViewModelManager 注入您的控制器，并使用它来构建您的 ViewModel。然后，在您的 ViewModelManager 实现中，您可以注入其他依赖项，如 repos、服务等，以实际构建您的 ViewModel。

这种方法肯定需要更多代码和更多类，但它会为您提供良好的粒度和分离度，并支持 DRY 原则和单一职责。

编码愉快！

【讨论】：

【解决方案4】：

作为一般规则，我认为您不想这样做。

作为该规则的一个例外，我在创建下拉菜单时开始在我的编辑器模板中使用一点服务定位器。我经历了多种填充下拉列表的方法（通常，将集合添加到视图模型或视图数据中的某种形式）。我看到一个视频，其中在编辑器模板中使用了 SL 来获取数据，然后转换为选择列表。我最初的反应是“啊，真的吗？”，但我越想越觉得有道理。

【讨论】：