8

我对模型-视图-控制器设计模式有疑问。我了解模型保存数据。我也了解控制器（View Controllers）实现应用程序的逻辑。例如，如果 UIPicker 轮选择第 4 行，则视图控制器可以向模型询问存储在模型数组中的第 4 个对象。我无法理解“视图”是否适合。我认为该笔尖/情节提要文件将被归类为“视图”。但是，每个视图都需要连接视图控制器以将所有出口连接到视图。我应该如何保持 View 和 View Controller 分开？我是否应该将所有插座连接到“视图类”，然后在我的视图控制器中引用我的“视图” 实现这些网点的逻辑时的类？也许我只需要一个 View 和 View Controller 处理不同任务的示例。因为否则额外的“视图”类似乎没有意义。MVC的View是指一个View Class吗？我如何或为什么要让这个 View Class 与我的 View Controller 类分开？

4

4 回答 4

14

视图的工作是显示数据和报告事件。

控制器的工作是协调视图和模型之间的通信。

数据的工作是存储数据并围绕该数据提供业务逻辑。

您询问：

我无法理解“视图”是否适合。

在您的示例中，UIPickerView是视图。

在 iOS/OSX 中，视图控制器只是 MVC 的控制器。碰巧视图控制器还包含一个空视图容器，您可以将所有其他视图添加到该容器中。但是在 iOS/OSX 中，MVC 还是有明显的分离。

UIButton像, UIPickerView,等所有类都UITableView代表视图。视图控制器的工作是为这些视图提供来自数据模型的数据以及响应来自这些视图的事件，让您有机会更新其他视图和数据模型。

你还说：

但是，每个视图都需要连接视图控制器以将所有出口连接到视图。我应该如何保持 View 和 View Controller 分开？

他们是分开的。如果添加一个UITableView，那是一个单独的视图。您将它连接到一个类，以便该类可以实现数据源和委托方法。该类是控制器类。这个控制器类通常是一个视图控制器，但它不是必须的。您可以编写独立于任何特定视图控制器（或通用控制器）的各种自定义视图类。但最终该视图类需要连接到 [视图] 控制器类，以便可以正确处理数据和事件。

您询问：

我如何或为什么要让这个 View Class 与我的 View Controller 类分开？

看UITableViewController。这是一个明显的分离示例，但它是在一个相当整洁的包中提供的。您实际上有一个单独的UITableView类，即视图。该视图负责呈现视图并收集用户交互。它是实际的表视图控制器，它向视图提供数据并处理来自视图的用户事件。

您可以将UITableView视图添加到任何视图。这是一个完全可重用的视图组件。连接到表视图的每个控制器都可以提供任何适当的数据并正确处理用户交互。

于 2013-02-05T23:27:14.393 回答
1

好的，我会尝试整理一下。

该模式称为模型-视图-控制器，从而将模型、视图和控制器明确分离。正如您正确指出的那样， ViewController 将事物放在一起（来自 View 和 Controller :)，实际上 ViewController 打破了强大的 MVC 模式。好消息是：如果您使用 ViewController，则不必将视图和控制器分开（猜猜它为什么这样命名？）。

现在我解释了为什么设计是这样的：

当您将视图和控制器强烈分离时，您基本上可以获得良好设计的学分。然而，事实证明，他们两个并不像我们希望的那样分开。不同的 GUI 表示通常确实需要不同的视图实现以及控制将模型转发到 GUI 的控制器的适配，例如控制台上的纯文本显示与位图上的绘图。在第一种情况下，您的控制器会将一个字符串传递给要渲染的视图，在第二种情况下，它还需要设置一些坐标才能将文本渲染到正确的位置。因此，您的控制器将经常更改。

理想的情况是实现模型和控制器，并简单地为任何人在现实生活中看到的任何东西提供视图。然而，在现实生活中，控制器很可能会适应视图，同时不理会模型。因此，将视图和控制器组合到包含特定视图并知道如何使用它的 ViewController 的设计决策只是一种合理的方式。

于 2013-02-05T21:58:35.870 回答
1

其实你的理解是完全错误的。

MVC 设计模式背后的核心原则是关注点分离。您将模型层与表示层分开，并且（在表示层中）将视图与控制器分开。

每个pars都有不同的责任：

  • 模型层包含所有的业务逻辑。这包括与存储、域逻辑和应用程序逻辑的交互。
  • view 负责 UI 逻辑。在 Web 的上下文中，这意味着该视图处理为用户创建响应
  • 控制器是接受用户输入的部分，并在此基础上改变模型层和当前视图的状态。

人们倾向于长期存在对 MVC的很多误解。例如：

  1. 有些人会坚持认为视图是愚蠢的模板。他们不是。

    MVC 设计模式中的视图是功能齐全的实例，处理可能使用也可能不使用多个模板来生成响应。

  2. 没有“模型”。模型是一个层，由多个不同的类组组成，每个类都有特定的任务。与表示层没有“表示”对象的方式相同

  3. 控制器不会将数据从模型层发送到视图。控制器只改变三元组其他部分的状态。视图实例本身从模型层请求他们需要的东西。

于 2013-02-05T22:18:28.820 回答
0

为了回答您的问题，让我们分解 MVC - 模型、视图、控制器。什么去哪里？

模型通常被认为是“做某事”层。这包含业务逻辑和数据逻辑。您的模型应该是 FAT，而不是 SKINNY，这意味着您的模型中应该有很多代码。

Controller ，我认为是“响应”层。这是您决定向用户返回什么的地方，无论是视图还是其他类型的响应，例如 JSON（在 RESTful 响应中特别有用）。您也可以使用模型，但您不应该在控制器本身中构建太多逻辑。你应该有一个 SKINNY 控制器。

视图主要是页面的标记——HTML 以及其他用于访问模型的标记——这取决于您使用的框架。我的经验是使用 MVC .NET，所以我会使用它。与 HTML 混合后，您将访问模型元素。视图中不应该有任何真正的逻辑，但您可以执行以下操作（使用 Razor 语法）

<div>@foreach person in Model.Users{
    <p>@person.FullName</p>
}
</div>

因此，您可以看到 View 可以有一些“显示逻辑”（例如，遍历人员并获取 FullName），但这就是您真正应该拥有的一切。

这是一个快速幻灯片，解释了有关 MVC 的更多信息，包括为什么您对“模型保存数据，控制器保存逻辑”的初始解释实际上不正确：http ://www.slideshare.net/damiansromek/thin-controllers-fat -models-proper-code-structure-for-mvc

MVC 设计模式不包括任何来自其他地方的称为“ViewController”的东西。

于 2013-02-05T22:09:47.557 回答