我的MVC模型应该如何与我的业务逻辑类一起使用？

Question

所以我有一个MVC应用程序，在另一个项目中，我有一个正常的类集合，它们处理应用程序的业务和数据逻辑。我在MVC项目本身的模型中也有一些逻辑。这个逻辑处理ViewModels之类的东西，这些东西在n层项目中是无法完成的，因为它们与MVC项目本身有关并且需要在同一个项目中。

我的问题是：

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

MVC应用程序中的ViewData / ViewModel类可能包含Model类的实例（我的）。我的控制器调用我的业务服务，负责ViewData和Models之间的任何转换。

  

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

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