我正面临 mvc 3 应用程序的设计问题。我有一个具有类别列表的视图模型 ProductCreateModel。
现在我在控制器中设置类别列表，但我想在 ProductCreateModel 构造函数中检测数据源是否是个好主意。
你认为视图模型应该是胖模型，也知道从数据源读取依赖数据吗？...或者这是一个控制器的东西？
问问题
984 次
4 回答
6
我更喜欢对数据层一无所知的苗条视图模型。它们更容易管理（根据我的经验）。
于 2012-07-31T12:52:24.587 回答
6
我认为视图模型应该是轻型模型，它们读取相关数据的唯一方法应该是“父”对象上的属性，即它们实际包装的模型。
大多数时候，我的视图模型只是具有属性的类，所有逻辑都在控制器或服务类中（如果我们正在谈论很多本来会放在控制器中的逻辑）。所有这一切都是为了更容易测试。
于 2012-07-31T12:54:01.217 回答
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 实现中，
这种方法肯定需要更多的代码和更多的类，但它会给您提供良好的粒度和分离度，并支持 DRY 原则和单一职责。
快乐编码！
于 2015-01-06T18:18:07.500 回答
0
作为一般规则，我认为您不想这样做。
作为该规则的一个例外，我在创建下拉菜单时开始在我的编辑器模板中使用一点服务定位器。我已经经历了多种填充下拉列表的方法（通常，将集合添加到视图模型或视图数据中的某种形式）。我看到一个视频，其中在编辑器模板中使用了 SL 来获取数据，然后转换为选择列表。我最初的反应是“啊，真的吗？”，但是，我越想越觉得有道理。
于 2015-01-06T18:32:01.673 回答