在控制器而不是模型中编写db查询被认为是不好的做法

Question

我读过最佳实践指示脂肪模型，瘦小的控制器。

模型应包含业务逻辑，例如根据从控制器发送的参数获取客户列表。

控制器应该包含足够的逻辑来调用模型中的方法以返回到视图。

但是我看到许多示例和教程，其中控制器中存在逻辑，例如访问数据库以获取产品列表的查询。我的印象是逻辑应该存在于模型中的方法中。然后，控制器可以调用此方法，而不是包含查询数据库的实际逻辑。

所以，如果我有一个ProductController，我可能会有一个返回索引视图的索引操作，而我会有一个ProductModel，它可以容纳我的逻辑，根据查询字符串显示某些产品（其中ProductController将传递给所述模型。正确？

Answer 1

  

因此，如果我有一个ProductController，我可能会有一个返回索引视图的Index操作，我会有一个ProductModel，它可以容纳我的逻辑，根据查询字符串显示某些产品（ProductController将传递给所述模型）。正确？

这是正确的。根据{{​​3}}：

  

模型管理应用程序域的行为和数据，   响应有关其状态的信息请求（通常来自   视图），并响应指令改变状态（通常来自   控制器）。在事件驱动的系统中，模型通知观察者   （通常是视图）当信息发生变化时，他们可以做出反应。

     

视图将模型渲染为适合互动的形式，   通常是用户界面元素。可以存在多个视图   用于不同目的的单一模型。视口通常有一个到   一个与显示表面的对应关系，并知道如何渲染   它

     

控制器接收用户输入并通过制作启动响应   调用模型对象。控制器接受来自用户的输入   指示模型和视口基于此执行操作   输入

将与数据相关的查询和操作保留在模型中;根据DRY（不要重复自己），你可以在那里尽可能多的东西。尽可能使函数可重用，以便可以将它们移植到各种控制器中，并在必要时在整个应用程序中使用。

视图应该包含很少 - 如果有的话 - 在视图特定工作之外的逻辑。

您的控制器函数应调用检索和操作数据所需的模型函数，并且应尽可能“精简”（如您所指出的）。控制器越小且涉及越少，就越容易在前端添加“不重启应用程序”的异步功能，从而提供更好的用户体验。 （如果你担心这一点，无论如何！）

Answer 2

VS 2010中的添加控制器对话框可以选择将带有CRUD功能的脚手架添加到控制器中。这应该告诉你相当多的ASP.NET MVC dev。团队观看了这场辩论。