MVC架构

Question

我希望您在MVC架构方面能够给予澄清。阅读一些文档时，我发现以下关系建立在Model-View和Controller之间。请帮助我理解这是如何实现的。

1. View查询模型的状态
2. 模型将状态信息传递给View

- Harish

Answer 1

MVC遵循一些简单的规则。

• 模型与控制器交互
• 控制器与视图交互
• 视图永远不会与模型交互。

你的模型通常映射到一个数据库表。例如，如果你有一个名为“blogposts”的表，它有两列，“title”和“body”，你可以这样做：

Blogpost.create(:title => "Hello", :body => "World")

你刚刚创建了一篇博客文章！现在，在你的控制器中，你需要执行以下操作：

blogs = Blogpost.find(:all)

现在，您可以将“blogs”变量传递到视图中，并决定如何向用户显示这些数据。如果我的示例代码不够清晰，很抱歉，它是用我当前选择的MVC语言Ruby（on Rails）编写的。

- Mike Trpcic

---

在我阅读的许多文章中，它们都说视图可以与模型交互。这只是该模式的非典型或规范版本。 - Dinah

Answer 2

一般来说，您所描述的工作将由控制器完成。控制器将查询模型，解释数据，并将其发送到视图以便以视图理解的形式进行显示。

然而，MVC并不是一个硬性规定。有许多解释，当正确执行比稍微违反规则更难看时，通常后者更可取。

- Andy Riordan

Answer 3

假设您有一个名为View的对象和一个名为Model的对象。每个对象都持有对另一个对象的引用。按照您描述的方式工作的方法是，View将调用Model中的一个函数，询问Model的状态，并且Model将返回它想要的信息。更有效的实现方式是，当某些内容发生变化时，Model会告诉State，然后View会请求它想要的信息。我手头没有代码示例，但您可能需要考虑使用观察者设计模式来实现这一点。

- mnuzzo

Answer 4

我曾经看到过一份描述MVC“三角形”形式的文件，我想某个时候有人让它工作了（要么就是关于它的文件只是在谈论未成形的产品）。然而，我并没有发现它在实际中有什么用途，因为它会导致严重的软件“工程”问题：循环依赖。如果你的视图依赖于模型的确切形状以进行某些查询，而模型依赖于控制器的确切形状，而控制器又依赖于视图的确切形状，那么实际上交换其中任何一个元素都变得相当不可能。

我发现拥有一个模型非常有用，它不依赖于除了一个简单的命令行程序所依赖的东西以外的任何东西。一个视图只依赖于您正在使用的任何GUI工具包或图形绘图API，而控制器则充当两者之间的代理，实现这种解耦。这是一种策略，使您可以创建模块化和可互换的模型和视图，只留下一个组件：具有所有这些讨厌依赖关系的控制器。

当然，可能会有某种“官方”的MVC模式版本，但我无法通过任何试图描述这种东西的文件，并以任何真正适用于现实世界系统的感觉来理解它。但也许我只是有点傻。

- Breton

---

是的，但如果你将视图、模型和控制器抽象成符合你心目中的模板，那么你就可以规避问题。你应该始终具有一定程度的抽象能力。我管理过几个工作正式的MVC程序，但你不必严格遵循这种模式。你可以根据自己的需要进行修改。它们更像是指导方针而不是实际规则。 - mnuzzo

我不确定你在这种情况下所说的“抽象”是什么意思。你是指提前决定部件之间的接口吗？我发现这种方法相当困难，我并不是一个足够优秀的程序员，在构建之前就能确定设计是否有效，并且在进行微调之前，我还没有机会进行构建，因此依赖于我在开始时设计的接口，而且无法更改听起来很可怕。也许你指的是其他东西。 - Breton

不，我的意思是一个抽象类或接口，其他类可以继承它以创建一种标准的类之间接口方式。但不要过度抽象，否则会产生其他问题。 - mnuzzo

这就是我认为你的意思。但我的同样担忧仍然存在。你到底什么时候设计那个接口？这有点像是把问题转移，而不是一个类依赖于另一个类，它依赖于抽象。也许我想太多了。也许我想得太少了。也许我只需要小睡一会儿。 - Breton

这就是为什么我通常使用Java的观察者模式。它提供了足够的抽象，你可以针对通知使用共同的类，但又不至于过于抽象，去定义所有可能的操作。在我看来，通知是唯一需要标准化的东西，其他的都可以直接处理。我在软件工程课上学到的一点是，没有东西可以真正做到独立，总会存在依赖关系。关键是要将依赖保持在可控范围内。 - mnuzzo