示例场景：屏幕上有5个视图，每次按下它时，每个视图都会通过彩色颜色增加一种颜色。
为了与MVC设计保持一致，它似乎鼓励拥有一个int或其他类型的模型，并且每次按下一个视图时它会告诉控制器“嘿，我被按下，只是fyi”然后让控制器说“好吧，我会把阵列中的相应位置增加一个”，然后让模型说“我改变了，无论谁关心”然后让视图说“我关心，所以我会改变颜色现在”。
^这对我来说似乎绝对荒谬。我想我必须有MVC完全倾斜的方式，因为将数据简单地存储在按钮本身似乎更有意义。当然，也许按钮的功能会改变或重复使用，所以当按钮被按下到它的代表（控制器）时，不要做什么，但这似乎有点多。
此外，是否建议在视图中存储ID？代表怎么知道哪一个被按下了？然后应该与模型一起保存相应的ID？这开始让我想起像意大利面条一样的mysql表......
无论如何，只是想确保我有正确的。
ps-我知道没有其他世俗的力量可以让我每次都使用MVC绝对完美，但是仍然想知道在这种情况下什么是合适的：）答案 0 :(得分：2)
在极限情况下，投资计划结构似乎有点矫枉过正。我们会将设计模式应用于“Hello World”计划吗？我们需要添加评论吗？没有“最佳实践”，只有“在这种情况下的适当实践”。
你的设置是一个极简主义的系统，有一个简单的模型和琐碎的关系 - 因此MVC可能有点过分。该应用程序的特殊功能：
现在让我们考虑应用程序的一个可能的变化：它是持久的。当你明天运行它时，它会从数据库中恢复状态，每次单击需要保存状态的按钮时。
您如何在极简主义解决方案中实现这一点？现在拥有一个知道如何坚持自己的共同模型开始具有价值。我声称MVC结构完全避免了这种变成意大利面。它强加了结构，并且该结构是维护者认可的广泛使用的结构。
我可能正在阅读你的问题，但听起来有点像你发现导航现有的MVC应用程序很麻烦。这与我曾经看到的，当有人习惯于编写小程序时遇到结构化或OO程序的情况类似：他们感到沮丧，因为没有单一的流程可以遵循，你不能轻易看到整体结构。我们需要学习的一件事是能够采用黑盒方法来编写代码。专注于一个（例如控制器）并暂时将模型和视图视为Black_Box。当我从一个方面转移到另一个大系统时，我发现自己几乎“换档”。