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

我正面临mvc 3应用程序的设计问题。我有一个viewmodel ProductCreateModel有一个类别列表。ASP MVC 3：ViewModels中的依赖注入是一个好主意吗？

现在我在控制器中设置类别列表，但我想如果在ProductCreateModel构造函数中合理化数据源是一个好主意。

你认为视图模型应该是脂肪的模型，也知道从数据源中读取相关数据？ ...或者这是一个控制器的东西？

来源

2012-07-31 Radu D

我更喜欢苗条的viewmodels，不知道关于数据层的事情。他们更容易管理（以我的经验）。

来源

2012-07-31 12:52:24

我认为视图模型应该是光模型，并为他们阅读相关数据，应该是“父”对象属性的唯一途径，该模型他们实际上换行。

大多数时候我的视图模型只是个教学班，性质，所有的逻辑都在控制器或在服务类（如果我们谈论了很多，否则将被放置在控制器逻辑）。所有这些都是以更简单的测试为名。

来源

2012-07-31 12:54:01

想知道，你是否在控制器的动作中实例化一个新的viewmodel类？然后从服务中逐个设置每个属性，例如，在操作中？你是否也用界面抽象了viewmodel？非常感谢 – Ian 2016-07-15 15:47:07

通常我会在action方法中实例化一个viewmodel类。根据视图模型与实际数据对象的相似程度，您可以使用自动映射器。我通常会创建一个ToViewmodel扩展方法，并在需要将数据对象“转换”为视图模型时使用它。我通常不会在viewmodels上使用接口。如果有意义的话，我可能会创建一个抽象的超类（其中几个视图模型共享大多数属性）。 – 2016-10-03 06:06:14

当我得知MVC我被教导的“经验法则”是瘦控制器，脂肪模型，阿呆意见。许多MVC开发人员犯的错误是Fat Controller（太多的逻辑），Skinny Models（基本上是POCO类来保存数据）和Smart Views（一堆Razor Syntax with If this，Else that等）

多年来，我坚持瘦瘦的控制器，胖模型，愚蠢的观点方法，并且它对我很好。现在，考虑到这与模型有关，而不是ViewModels。通常你的模型应该在一个完全不同的层次上（即proj或文件夹）。另一方面，ViewModels应该相当简单。这使得它们更容易测试，并且更易于重用。如果您发现需要某种服务，回购或其他依赖来构建ViewModel，那么您应该将该逻辑抽象为某种Composer类。在过去，我使用了实现IViewModelManager的ViewModelManager，如果需要的话可以组合我的ViewModel。这样，您可以将IViewModelManager注入到控制器中，并使用它来构建ViewModel。然后，在您的ViewModelManager实现中，您可以注入其他依赖项，如repos，services等，以实际构建您的ViewModel。

这种做法无疑需要更多的代码，多类，但它会给你粒度的良好水平，和分离，加上支持DRY原则与单一责任一起。

快乐编码！

来源

2015-01-06 18:18:07

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

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

来源

2015-01-06 18:32:01 SwampyFox

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

回答

相关问题