4

我有一个服务层，将方法暴露给我的 MVC '层'。可以说我有一个方法：

Public List<StateObjects> GetStates()

然后从我的模型对象的构造函数调用该方法来为我的视图构建一个状态选择列表是好还是坏的设计？模型是否应该引用我的服务层，并且还允许我的控制器引用我的服务层？还是应该在控制器中完成模型变量的填充，所以所有逻辑都在控制器中？

4

4 回答 4

3

根据应用程序的大小和范围，这可能不是一个明确的答案，但是当与服务层结合使用时，我倾向于使 MVC 的“M”更像是一个视图模型。

与 MVVM 类似，模型成为一个平面对象，仅包含将显示给视图的属性。控制器访问服务层，然后使用AutoMapper将域对象的属性映射到模型。

你最终得到的是瘦控制器和瘦模型，大部分逻辑都留在你的服务层。模型真正具有任何逻辑的唯一时间是将列表（例如您的 StateObject 列表）映射到 SelectList，或其他与视图相关的函数/计算。如果您正在进行任何类型的异步 JavaScript 开发，它还允许您轻松地将模型映射到 JSON 对象，因为模型相对扁平。

让您的模型直接引用您的服务层意味着如果您尝试使用某种类型的依赖注入，则必须将所有服务传递给构造函数，这会使模型的实例化变得非常痛苦。

我不知道这是否打破了 MVC 范式，但它在我过去做过的项目中运行良好。

于 2012-08-25T00:07:30.130 回答
2

答案是：

这取决于您的应用程序和编码风格。

很多人练习精益模型和肥控制器，但是来自沉重的面向对象背景，拥有肥模型和精控制器感觉更自然。这是我的想法：

模型应该了解自己。这意味着依赖于模型的函数属于模型。

模型应该与其他模型无关。控制器应该处理模型到模型的交互（以及不单独涉及实例的其他交互）。

这样你就可以拥有优雅instance.function()和controller.staticLikeFunction().

IMO 这是在你有一个面向对象的应用程序的情况下最漂亮的方法。

如果您的应用程序不需要面向对象的设计，那就没有意义了。在这种情况下，将所有内容都放入控制器并保留您的模型纯数据。

于 2012-08-25T00:14:16.340 回答
0

最好使用视图模型作为模型，并保持精简。它应该只有足够的信息来与视图和控制器通信，仅此而已。

控制器所需的其他逻辑可以包含在类中，并由控制器实例化。这使您的逻辑保持松散耦合，因此更易于维护。你会帮自己一个忙。

于 2012-08-25T04:26:59.423 回答
0

正如您所指出的，有两个真正的选择：

  • 使用从业务/域层返回的数据在控制器中填充模型
  • 通过其构造函数、属性或方法在模型中填充模型数据。

还有第三种选择，即在您的域层中拥有 MVC 的 MC 部分。这使得模型填充变得更容易，但确实有点模糊了业务层所做的界限（如果您是纯粹主义者）。实际上，在您建立一个巨大的企业模型之前，这并不重要。

我特别喜欢有一个静态的

public static MyModel FromDomainObject(DomainObject object)

模型上的方法。然后，您可以在控制器中使用它并在操作中传递域对象以获取模型，然后将其传递给您的视图。

重要的部分是确保模型中的属性不会按需填充，并且视图无法访问方法。实际上，您或团队将调用这些方法/属性并知道其含义，但这有助于保持关注点的分离并减少耦合。

于 2012-08-25T00:30:23.487 回答