我对模型视图控制器设计模式有疑问。
我将解释我对我的问题的看法。
如果在我的模型中，我有一个名为 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吗？
由于
答案 0 :(得分：0)
现在我的问题是，那是MVC吗？
从纯粹的技术角度来看，不，因为你实际上没有一个单独的控制器，但它是朝着正确方向迈出的一步;）
我读到一些关于MVC的内容是关于发送模型来为该模型创建所有不同类型的视图，但我的想法是，如果将不同的模型传递到视图中，视图相同。这算作MVC吗？
这是正确的，但我认为你可能误解了它的含义。该模型不关心视图，它不关心数据的表示方式，它只关心持有视图所期望的合约（由interface指定）。
同样，视图并不关心模型是如何实现的，只是模型会保持interface的合约。
这意味着模型可能被多个不同的视图使用，这些视图以不同的方式表示数据。同样，它可能只有一个可视化。关键是，模型不应该关心。
所以我想说你的观点是可以的。视图可以代表其生命周期内的多个模型
请记住，像MVC范例这样的观点是明确区分和定义层之间的责任，并解除层之间的关系。
在iOS开发中，模型和视图之间存在明显的分离，以至于两者之间不应相互影响，事实上，它们之间的所有通信都由控制器处理。这有时看起来很不一致，因为您希望模型告诉视图更新某些内容。
通过允许控制器在这种情况下充当模型和视图之间的代理或委托，您实际上进一步解耦了关系，因为您可以在新控制器中滑动，该控制器可能具有自己的视图并提供插件功能有鉴于此，你应该不在乎。
正好让你现在感到困惑;）