2

所以我有一个 MVC 应用程序，在另一个项目中，我有一个普通的类集合，用于处理应用程序的业务和数据逻辑。我在 MVC 项目本身的模型中也有一些逻辑。此逻辑处理 ViewModel 等，这些事情在 n 层项目中无法完成，因为它们与 MVC 项目本身相关并且需要在同一个项目中。

我的问题是：

  • 我的模型类是否应该了解 n 层业务逻辑？还是应该只有控制器拥有这些知识并根据需要在 n 层应用程序和 MVC 模型之间来回发送数据？
  • 如果我的模型可以引用 n 层应用程序，那么我的控制器是否应该通过模型类访问 n 层？

希望这是有道理的，发现很难正确地表达我的观点。

4

3 回答 3

3

一般来说这里 - 你的模型类不应该有业务逻辑知识。他们应该只有向用户显示视图所需的信息（使用 mxmissile 建议的 DTO）。

您的业​​务逻辑可以在您的控制器中，或者（更好）在您的控制器调用的单独服务层中。例如，在模型上使用绕过控制器并直接调用数据库的方法几乎总是一种不好的做法。

这里的想法是使视图尽可能愚蠢。你向他们发送一个模型，他们提取他们需要的数据，适当地格式化并显示它。如果您决定要更改演示文稿，这使得以后创建相同数据的新视图变得更加容易。

于 2009-07-06T16:29:13.037 回答
1

将模型视为控制器和视图之间数据的唯一容器。本质上是 DTO。

于 2009-07-06T16:17:02.110 回答
0

MVC 应用程序中的 ViewData/ViewModel 类可能包含模型类的实例（我的就是这样）。我的控制器调用我的业务服务并负责 ViewData 和模型之间的任何转换。

如果我的模型可以引用 n 层应用程序，那么我的控制器是否应该通过模型类访问 n 层？

我不会通过模型进入应用程序层，我会让控制器成为那个接口组件。控制器调用您的应用程序层，从您的数据访问组件返回模型的实例。然后，您可以使用 ViewData/ViewModel 对象将这些实例转换为更多可消耗的对象。您可以在控制器中执行此操作，或使用单独的汇编程序类。

于 2009-07-06T16:29:50.960 回答