模型视图控制器混淆

Question

我有一个关于模型视图控制器设计模式的问题。

我将解释我对我的问题的想法。

如果在我的模型中有一个名为 iModel 的界面。我有两个实现 iModel 的类。第一类称为 Game1，第二类称为 Game2

在我的视图包中，我有一个 Gui 类，它接收一个 iModel 实例并使用 iModel 实例制作游戏。例如 GUI(iModel m)

由于我通过了 iModel，我可以通过两种不同的游戏，但一次只能通过一种。

一场比赛

iModel m = new Game1(); 

在视图中，Gui(m) 将创建 Game1

其他游戏

iModel m2 = new Game2(); 

看来，Gui(m2) 会创建 Game2

现在这个概念基本上是我将多个模型（一次只有一个）传递到视图中。视图将是相同的，但根据选择的游戏（模型）具有不同的数据。

现在我的问题是，那是 MVC 吗？我读了一些关于 MVC 的东西是关于发送一个模型来为该模型创建所有不同类型的视图，但我的想法是，如果将不同的模型传递到视图中，并且视图是相同的。这算作 MVC 吗？

谢谢

Answer 1

现在我的问题是，那是 MVC 吗？

从纯粹的技术角度来看，不，因为您实际上没有单独的控制器，但这是朝着正确方向迈出的一步；）

我读到一些关于 MVC 的内容是关于发送一个模型来为该模型创建所有不同类型的视图，但我的想法是，如果将不同的模型传递到视图中，并且视图是相同的。这算作 MVC 吗？

没错，但我想你可能会误解它的意思。模型不关心视图，也不关心数据如何表示，它只关心维护视图期望的合同（由interface 指定）。

同样，视图不关心模型是如何实现的，只关心模型维护interface 的合同。

这意味着一个模型可能被多个不同的视图使用，这些视图以不同的方式表示数据。同样，它可能只被一个人可视化。关键是，模型不应该关心。

所以我想说你的观点是好的。一个视图可以在其生命周期内表示多个模型

请记住，类似于 MVC 范式的要点是明确分离和定义层之间的责任，并解耦层之间的关系。

深思……

在 iOS 开发中，模型和视图有明确的分离，以至于两者都不应该相互交互，实际上它们之间的所有通信都由控制器处理。这有时看起来很矛盾，因为您希望模型告诉视图更新某些内容。

在这种情况下，通过允许控制器充当模型和视图之间的代理或委托，您实际上可以进一步解耦关系，因为您可以滑入一个可能有自己的视图并为插件提供功能的新控制器看来，重点是，你不应该在意。

所以你现在完全糊涂了；）