我听说控制器应该保持清晰，模型很重。
我对控制器中应保留的内容以及模型中应保留的内容的最佳实践感到有些困惑。
在我们的组织中，我们使用实体框架，并将表放在那里。
对于控制器，我们使用LINQ，然后将信息发送到视图。
对控制器和模型中应该包含哪些代码感到困惑。
答案 0 :(得分：11)
免责声明
整个主题是一个巨大的混乱。特别是在Web MVC方面。出于所有实际目的，不可能将经典的MVC模式用于web，因为视图应该是观察模型。从理论上讲，你可以使用WebSockets实现类似的功能，但为每个用户保留持久模型并不是一个现实的解决方案。
经典MVC和MVC启发模式中最重要的概念Separation of Concerns。它将应用程序分为两个主要层：
表示层
管理用户界面。它处理接口的创建并对用户对此接口的操作做出反应。此接口可能是桌面应用程序或HTML网页的GUI，但它也可以是Mars漫游器上的REST API或接收器响应程序。这就是Web应用程序可以在前端和后端实现MVC模式的原因。
强制部分是视图和控制器，但是在Web环境中，完全实现的视图通常也使用多个模板来创建界面。
模型层
这是所有业务规则和逻辑的所在。 MVC中的 M 不是单个实体。相反，它是一个包含不同结构的图层。其中一些结构也负责与存储的交互。
控制器是表示层的一部分，它处理用户输入。在基于Web的实现的上下文中，您通常在视图和控制器之间具有1：1的关系，其中控制器从浏览器接收请求，并且基于所述请求的内容，改变模型层和视图的状态。
如果您使用的是经典的MVC或Model2 MVC，那么这就是控制器职责的范围。
在具有被动视图的MVP和MVVM模式中，类似控制器的结构负责从模型层获取信息并将其传递给当前视图实例。 This post可能会提供有关MVC启发模式的其他详细信息。
但是控制器决不对任何形式的业务逻辑负责。如果它是，那就意味着你有一个泄漏的抽象，因为表示层的结构将起作用，应该在模型层中。
通常，控制器将是您应用程序中最简单的结构。
如前所述，model是一个层，它包含所有域业务逻辑和相关功能。该层与表示层一样，由多组结构组成：
域对象 [1]
这些结构通常是人们在谈论“模型”时的意思。它们也称为model objects或business objects。这是大多数域业务逻辑最终的地方。
数据存储结构
该组将包含所有类，这些类抽象了与存储的交互（SQL数据库，缓存系统，noSQL，远程SOAP或REST API）。它们通常会实现data mapper或repository模式的某些变体，但您也可以使用其他一些解决方案，例如unit of work。实施细节并不那么重要。 的重要之处在于，它们允许您存储数据并将信息检索到域对象中。
<强>服务
或者您可以调用“组件”。模型层中有高级抽象，便于域对象和存储结构之间的交互。通常代表模型层的大块，如“识别服务”，“邮件程序”，“文章管理”，并将提供表示层与之交互的界面。
答案 1 :(得分：1)
这是一场宗教辩论。 有些人喜欢尽可能少的代码在他们的控制器和其他尽可能少的模型中。 在项目中做你感觉自然的事情，但要在其中保持一致。
所有其他都是教条，你可以选择一个例子，并提出案例。
答案 2 :(得分：0)
模型是您的应用程序的核心。最好将模型视为您的业务实体。您想创建发票视图吗？然后Invoice成为您的模型，它代表底层对象。
Controller只是一种处理来自客户端的请求，从数据库中检索数据（或更新它们）以及清除响应的方法。
您对应用程序设计的看法应该以模型为中心，这是重要的部分。
答案 3 :(得分：0)
简单来说，Model表示应用程序将使用的基础数据。它的设计方式可以在不同的应用程序中使用。 例如，控制台命令，Web服务等可以使用表示新闻数据的模型。 在模型中，您将定义您的业务逻辑，与视图无关。
控制器可以被认为是将Model和View绑定在一起的粘合剂。它们直接处理客户端请求，因此与视图和模型进行交互。
在设计良好的应用程序中，您将设计数据结构和业务逻辑 模型，使它“沉重”。虽然Controller只是将您的模型和视图与客户端请求相互链接，使其“轻松”。
答案 4 :(得分：-1)
我不是MVC专家，但请注意控制器应该使用用户的输入来指导他们正确的视图。
我不知道NerdDinner是否是一个理想的例子，但你可以看到Scott Hanselman等人从他的EF上下文中做了一些数据访问，但是将大部分其他逻辑推送到服务类或帮助者在模型上。
我不知道我是否同意'模型重'部分，因为我不将模型用作'业务对象'。如果我真的需要很多“业务”逻辑，我通常会在一个单独的“域”层中创建它，甚至可能在此之上有一个单独的数据访问层。但是对于很多简单的（参见：非企业）项目，这在我的经历中是过度的。
答案 5 :(得分：-1)
在经典的模型 - 视图 - 控制器MVC模式中，您的模型本质上是一个“无头”应用程序，没有UI，完全是UI不可知。它提供的API是应用程序的功能核心。
View是用户界面，但是你选择定义它（网页？电梯控制面板？还有其他什么？）。给定的应用程序可能有1个视图，也可能有很多视图。
控制器（或控制器 - 类似于视图，您可能拥有一个或多个给定应用程序的控制器）在视图和模型之间中继和转换事件，通知和数据，以防止模型需要知道任何视图特异性。
这个想法是将核心应用程序（Model）与用户界面（View）隔离开来。从那以后有些事情如下：
View了解并与Controller和Model进行通信（您不太可能尝试将View连接到另一个模型），并期望Controller能够同时了解View和Model。
Controller了解并与View和Model进行通信。
模特对控制器或视图一无所知。
执行业务逻辑的代码应该在Model中，而不是在Controller中。