Question

我对模型 - 视图 - 控制器设计模式有疑问。我理解该模型包含数据。我也了解Controller（View Controllers）实现app的逻辑。例如，如果UIPicker轮选择第4行，则视图控制器可以向模型询问存储在模型阵列中的第4个对象。我很难理解“视图”是否合适。我认为该笔尖/故事板文件将被归类为“视图”。但是，每个视图都需要连接一个View Controller，将所有插座连接到视图。我怎么想保持View和View Controller分开？我应该将所有插座连接到“View Class”，然后在我的View Controller中引用我的“View”类来实现这些插座的逻辑吗？也许我只需要一个View和View Controller处理不同任务的例子。因为否则额外的“视图”类似乎没有意义。 MVC的视图是指View类吗？我希望如何或为什么要将此View类与View Controller类分开？

Answer 1

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

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

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

你问：

我很难理解＆＃34;观看＆＃34;适合。

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

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

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

您还说：

但是，每个视图都要求连接一个View Controller，将所有插座连接到视图。我怎么想让视图和视图控制器分开？

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

你问：

我想如何或为什么要将此View Class与View Controller类分开？

看看UITableViewController。这是分离的一个明显例子，但它是以一个相当整洁的包装提供的。实际上你有一个单独的UITableView类，它是视图。此视图负责呈现视图和收集用户交互。它是实际的表视图控制器，它为视图提供数据并从视图中处理用户事件。

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

Answer 2

好的，我会尝试解决一些问题。

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

现在我对设计原因的说法非常简单：

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

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

Answer 3

实际上你所理解的是完全错误的。

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

每个人都有不同的责任：

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

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

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

MVC设计模式中的视图是完全功能的实例，处理可能会或可能不会使用多个模板来生成响应。
没有“模特”。模型是一个层，由多个不同的类组组成，每个类都有特定的任务。与表示层
控制器不会将数据从模型层发送到视图。控制器仅更改三合一的其他部分的状态。视图实例本身从模型层请求他们需要的内容。

Answer 4

很好地回答你的问题让我们分解MVC - 模型，视图，控制器。怎么回事？

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

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

视图主要是页面的标记 - HTML以及用于访问模型的其他标记 - 这取决于您使用的框架。我的经验是使用MVC .NET，所以我会继续使用它。与HTML混合后，您将访问Model元素。视图中不应该有任何真实的逻辑，但你可以做（如使用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”的东西，它来自其他地方。

MVC设计模式。 View如何适合它？

4 个答案: