Question

我一直在使用MVC模式一段时间，但老实说，我不觉得我真的懂得如何使用和应用“模型”...我的意思是，一个人可以很容易地逃脱只使用Controller和View就可以了。

我理解模型的概念，但我觉得在模式中应用它并不舒服......我在.NET中使用MVC模式，在ColdFusion中使用Wheels。

“模型代表应用程序的信息（数据）和用于操纵数据的业务规则” - 是的，我明白了......但我真的不明白如何应用它。将呼叫路由到Controller并让Controller调用数据库，组织数据然后将其提供给View更容易。我希望有人明白我的困惑在哪里......

我提前感谢您的帮助！

Answer 1

这样看。当您的客户请求页面时，会发生这种情况（大规模修剪）：

他最终在你的控制器
控制器从模型中获取必要的数据
然后控制器将数据传递到视图，这将创建HTML
控制器将HTML发送回客户端

所以客户 - ＆gt;控制器 - ＆gt;模型 - ＆gt;控制器 - ＆gt;查看 - ＆gt;控制器 - ＆gt;客户端

那么什么是模型？获取您需要的数据所需的一切都是必需的！

这是服务
这是数据访问
这是查询
是对象映射
关键的'抛出异常'样式验证

如果您坚持使用该模式，您的控制器应不编写您的查询。您的控制器应该获得正确的数据以呈现正确的视图。

您的控制器可以执行其他一些操作，例如验证发布的数据或某些if / else逻辑，但不查询数据 - 仅调用服务（在您的模型区域中）以获取您查看所需的数据。

Answer 2

我想这就是你决定调用应用程序中不同位的内容。无论您使用哪种类将信息从Controller传递到View，都可以看作/称为“模型”。

通常我们调用Model我们的实体类，并且我们将View Model称为“辅助”类，因为缺少更好的单词，我们在“纯”实体（即将使用存储在数据库中）不足以显示我们在View中需要的所有信息，但它主要是命名的东西。

您的模型类不应具有任何功能; 理想情况下模型类只有属性。您应该将模型类视为数据容器，信息传输器。除此之外，他们（主要）是“哑”的对象：

// This would be a model class representing a User
public class User
{
    public int ID { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

如何将控制器实际传递给您的视图（反之亦然）？那么，这就是你的模特。：）

Answer 3

以下是我之前解释的方式：

控制器：确定执行，包含等文件，并将用户输入（如果存在）传递给这些文件。
查看：用于向用户显示输出的任何内容。
型号：其他所有内容。

希望有所帮助。

Answer 4

Model是基础对象的代码表示。虽然MVC模型端的一些数据密集程度较低的系统可能很少，但我相信您总能找到适用的用途。

让我们以一个人为的（但现实的）例子来说明模型的用处：

说我正在制作博客。我的博客有Post对象。现在，帖子在网站内部和周围使用，并由系统中的许多用户添加。我们的系统编码为人们在他们的帖子中输入HTML，但是很低，人们开始添加粘贴的文本。本文使用“\ n”作为换行符。

使用模型，这是一个相对简单的修复。我们只是制作一个覆盖postText的getter：

public function get postText() {
    return this.postText.replace("\n", "<br />");
}

突然间，我们可以通过几行简单的代码来影响整个网站的行为。如果没有模型的实现，我们需要在使用postText的地方找到并添加类似的功能。

MVC中的模型是关于代码库随着时间的推移而发展的封装和灵活性。你越多地使用它并以这种方式思考它，你就越会发现其他本来就是噩梦的案例。

- 编辑（您已添加到上面的问题中）：

让我们采用相同的示例并使用您的Controller调用数据库。我们有9个Controller类用于使用Post对象的各种页面/系统。我们的Post表现在需要delete_fl。我们不再希望使用delete_fl = 1加载帖子。

正确实施我们的帖子模型后，我们只需编辑loadPosts()方法，而不是搜索网站上的所有案例。

一个重要的实现是，在任何主要系统中，模型都比单个整体更多地是文件集合。通常，每个数据库表都有一个Model文件。用户，邮政等

Answer 5

model: word, sentence, paragraph
controller: for (word in sentence), blah blah... return paragraph
view: <div>paragraph.text</div>

这个想法是将问题分开。为什么不在视图中同时拥有控制器逻辑呢？模型表示业务对象，控制器操纵这些对象以执行某种任务，视图显示结果。这样，您可以将整个视图交换为另一个视图，而不必重写整个应用程序。您还可以让人们在不同的图层（模型，控制器，视图）上工作，而不会在很大程度上影响其他图层。

通过组合控制器和模型，您可以减少代码的可维护性和可扩展性。您基本上没有执行面向对象的编程，因为您没有将数据库中的内容表示为对象，您只是将数据取出并将其发送到视图。

Answer 6

该模型包含业务逻辑（即重要算法）和持久性交互 - 通常与数据库相关。控制器是MVC 框架：Wheels，Struts，.NET的MVC方法。该视图显示控制器从模型中检索的数据。

MVC的重要思想是视图和模型应该不知道控制器 - 即没有耦合。在实践中，至少存在一些耦合，但是当做得好时应该是最小的，这样它可以用很少的努力来改变控制器。

所以应该发生的是请求命中控制器，通常是front controller，其中应该有一些您编写的粘合代码，它们可以扩展某些控制器对象或遵循一些命名约定。此粘合代码负责在正确的service layer对象上调用方法，将该数据打包到某种帮助程序（通常是Event对象）中，并将其发送到正确的视图。然后，视图将从Event对象中解压缩数据并相应地显示。

如果做得好，这会产生一个可以单元测试的domain model（a.k.a。模型）。这样做的原因是您已将算法与任何框架或视图依赖关系分离。这样您就可以独立验证这些。

MVC：我需要了解模型

6 个答案: