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

Question

我面临着mvc 3应用程序的设计问题。我有一个viewmodel ProductCreateModel，它有一个Categories列表。

现在我在控制器中设置Categories列表，但我在想是否在ProductCreateModel构造函数中对数据源进行indect是一个好主意。

您是否认为视图模型应该是胖模型，也知道从数据源读取相关数据？ ......或者这是控制器的事情？

Answer 1

我更喜欢不了解数据层的苗条视图模型。它们更容易管理（根据我的经验）。

Answer 2

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

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

Answer 3

当我学习MVC时，我被教导了＆＃34;经验法则＆＃34;是瘦的控制器，脂肪模型，哑视图。许多MVC开发人员犯的错误是Fat Controllers（太多逻辑），Skinny Models（基本上用于保存数据的POCO类）和Smart Views（一堆Razor语法，如果这个，Else等等）

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

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

快乐的编码！

Answer 4

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

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