10

我听说控制器应该保持轻便而模型要重。

对于控制器中应该保留什么以及模型中应该保留什么的最佳实践，我有些困惑。

在我们的组织中，我们在哪里使用实体框架并将表放在那里。

对于控制器，我们使用 LINQ，然后将信息发送到视图。

对控制器和模型中应该包含哪些代码有点困惑。

4

6 回答 6

11

免责声明
整个话题是一团糟。尤其是在涉及 Web MVC 时。出于所有实际目的，不可能将经典的 MVC 模式用于 Web，因为视图应该是观察模型。从理论上讲，您可以使用 WebSockets 实现类似的东西，但是为每个用户保留一个持久模型并不是一个现实的解决方案。

这是你必须了解的 MVC

经典 MVC 和受 MVC 启发的模式中最重要的思想分离关注点。它将应用程序分为两个主要层：

  • 表示层

    管理用户界面。它处理界面的创建和对用户对该界面的操作作出反应。该接口可能是桌面应用程序或 HTML 网页的 GUI，但它也可以是 REST API 或火星探测器上的接收器-响应器。这就是为什么 Web 应用程序可以在前端和后端实现 MVC 模式的原因。

    必需的部分是视图和控制器，但在 web 上下文中，完全实现的视图通常也使用多个模板来创建界面。

  • 模型层

    这是所有业务规则和逻辑所在的地方。MVC 中的M不是一个单一的实体。相反，它是一个包含不同结构的层。其中一些结构还负责与存储的交互。

控制者的职责是什么？

控制器是表示层的一部分，它处理用户输入。在基于 Web 的实现的上下文中，视图和控制器之间通常具有 1:1 的关系，其中控制器接收来自浏览器的请求，并根据所述请求的内容更改模型层和视图的状态。

如果您使用的是经典 MVC 或 Model2 MVC，那么这就是控制器职责的范围。

在 MVP 和 MVVM 模式中，您有一个被动视图，类似控制器的结构负责从模型层获取信息并将其传递给当前视图实例。这篇文章可能会提供一些关于受 MVC 启发的模式的额外细节。

但控制器绝不负责任何形式的业务逻辑。如果是，则意味着您有一个泄漏的抽象，因为表示层的结构会起作用，这应该在模型层中。

通常，控制器将是您应用程序中最简单的结构。

模型呢？

如前所述，模型是一个层，它包含所有领域业务逻辑和相关功能。该层，就像表示层一样，由多组结构组成：

  • 领域对象[1]

    在谈论“模型”时，这些结构通常是人们的意思。它们也称为模型对象或业务对象。这是大多数领域业务逻辑结束的地方。

  • 数据存储结构

    该组将包含所有类，它们抽象与存储的交互（SQL 数据库、缓存系统、noSQL、远程 SOAP 或 REST API）。他们通常会实现一些数据映射器或存储库模式的变体，但您也可以使用其他一些解决方案，例如工作单元。实现细节并不那么重要。重要的是它们允许您从域对象中存储数据并将信息检索到域对象中。

  • 服务

    或者你可以称之为“组件”。模型层中有高级抽象，有助于域对象和存储结构之间的交互。通常代表模型层的大块，如“识别服务”、“邮件”、“文章管理”，并为表示层提供交互的接口。

于 2012-08-19T15:21:24.843 回答
1

这是一场宗教辩论。有些人喜欢在他们的控制器中尽可能少的代码，而在他们的模型中尽可能少的代码。在项目中做你觉得自然的事情，但要保持一致。

其他一切都是教条，您可以选择任何一种方式并提出案例。

于 2012-08-17T21:11:43.457 回答
0

Model is the core of your application. It is best to think of models as of your business entities. Do you want to create a view of an invoice? Then Invoice be your model, it represents the underlying object.

Controller is just a way to handle requests from a client, retrieving the data from database (or updating them) and flushing out the responses.

Your thoughts about the application design should be model-centric, that's the important part.

于 2012-08-17T20:43:11.083 回答
0

简单来说，Model 表示您的应用程序将使用的底层数据。它的设计方式应使其可以在不同的应用程序中使用。例如，控制台命令、Web 服务等可以使用表示新闻数据的模型。它在模型中，您将在其中定义业务逻辑，独立于视图。

控制器可以被认为是将模型和视图绑定在一起的粘合剂。它们直接处理客户端请求并相应地与视图和模型进行交互。

在一个设计良好的应用程序中，您的数据结构和业务逻辑将被设计在一个模型中，使其“沉重”。而控制器只会将您的模型和视图与客户端请求互连，使其“轻”。

于 2012-08-17T20:55:02.790 回答
-1

在经典的模型-视图-控制器 MVC 模式中，您的模型本质上是一个“无头”应用程序，没有 UI，并且完全与 UI 无关。它提供了一个 API，它是应用程序的功能核心。

视图是用户界面，但您选择定义它（网页？电梯控制面板？其他？）。给定的应用程序可能有 1 个视图，也可能有很多视图。

控制器（或多个控制器——就像视图一样，对于给定的应用程序可能有一对多控制器）在视图和模型之间中继和转换事件、通知和数据，以防止模型需要知道任何特定于视图的东西。

这个想法是将核心应用程序（模型）与用户界面（视图）隔离开来。从中可以看出一些事情：

  • View 知道 Controller 和 Model 并与之通信（您不太可能尝试将 View 连接到另一个 Model）并期望 Controller 知道 View 和 Model。

  • Controller 知道 View 和 Model 并与之通信。

  • 模型对控制器或视图一无所知。

执行业务逻辑的代码应该在模型中，而不是在控制器中。

于 2012-08-17T21:09:21.553 回答
-1

我不是 MVC 专家，但试着专注于控制器应该使用来自用户的输入来引导他们到正确视图的事实。

我不知道NerdDinner是否是一个理想的例子，但您可以看到 Scott Hanselman 等人从他的 EF 上下文中进行了一些数据访问，但将大部分其他逻辑推送到模型上的服务类或助手。

我不知道我是否同意“模型重”部分，因为我不将模型用作“业务对象”。如果我真的需要很多“业务”逻辑，我通常会在单独的“域”层中创建它，甚至可能在此之上有一个单独的数据访问层。但是对于很多简单的（请参阅：非企业）项目，根据我的经验，这是矫枉过正的。

于 2012-08-17T20:40:26.733 回答