模型视图控制器（MVC）设计模式-如何将多个视图链接到多个模型？
示例场景：屏幕上有 5 个视图，每次按下时，每个视图的彩虹颜色都会增加一种颜色。
为了与 MVC 设计保持一致，它似乎鼓励拥有一个由整数数组或其他东西组成的模型，每次按下视图时，它都会告诉控制器“嘿，我被按下了，仅供参考”，然后让控制器说“好吧，我会将数组中相应的位置加一”，然后让模型说“我改变了，不管谁在乎”，然后让视图说“我在乎，所以我现在要改变我的颜色”。
^这对我来说绝对是荒谬的。我想我必须让 MVC 的工作方式完全倾斜，因为将数据简单地存储在按钮本身中似乎更有意义。当然，也许按钮的功能会改变或被重用，所以把按下按钮时要做什么留给它的代表（控制器），但这似乎有点多了。
另外，是否建议在视图中存储 ID？代表还如何知道哪一个被按下了呢？那么模型应该保存一个对应的ID吗？这开始让我想起意大利面条般的 mysql 表...
无论如何，只是想确保我的正确性。
ps-我知道没有其他世俗力量要求我每次都绝对完美地使用 MVC，但仍然想知道在这种情况下什么被认为是正确的:)
Example scenario: 5 views on the screen that each increment through the colors of the rainbow by one color each time you press it.
In keeping with the MVC design, it seems to encourage having a model that is an array of ints or something, and every time a view is pressed it tells the controller "hey, I'm pressed, just fyi" and then have the controller say "ok, I will increment your corresponding spot in the array by one" and then have the model say "I'm changed, whoever cares" and then have the view say "I care, so I will change my color now".
^That seems absolutely absurd to me. I'm thinking I must have the way MVC should work completely skewed, as it seems to make much more sense to simply store the data in the button itself. Sure, maybe the functionality of the button will change or be reused so leave what to do when the button is pressed up to its delegate (the controller), but this seems a bit much.
Also, is it then recommended to store an ID with the view? How else will the delegate know which one was pressed? Then a corresponding ID should be saved with the model? This is starting to remind me of spaghetti-like mysql tables...
Anyways, just want to make sure I have that correct.
ps- I am aware that there is no other worldly force out there that MANDATES I use MVC absolutely perfectly every time, but would still like to know what is considered proper in this scenario :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在有限的情况下，对项目结构的投资可能看起来有点矫枉过正。我们会将设计模式应用于“Hello World”程序吗？我们需要添加评论吗？没有“最佳实践”，只有“这种情况下的适当实践”。
您的设置是一个极简主义系统，具有琐碎的模型和琐碎的关系 - 因此 MVC 可能有点矫枉过正。该应用程序的特点：
现在让我们考虑一下应用程序可能发生的一项更改：它是持久性的。当您明天运行它时，它会从数据库恢复状态，每次单击按钮时都需要保存状态。
您将如何在您的极简解决方案中实现这一点？现在，拥有一个知道如何持久化的通用模型开始变得有价值。我认为 MVC 结构完全避免了这种变成意大利面条的情况。它强加了结构，并且该结构是维护者会认可的广泛使用的结构。
我可能对你的问题读得太多了，但这听起来有点像你发现导航现有的 MVC 应用程序很麻烦。这与我在习惯于编写小程序的人遇到结构化或面向对象程序时所看到的反应类似：他们会感到沮丧，因为没有单一的流程可遵循，您无法轻易看到整体结构。我们需要学习做的一件事是能够采用黑盒方法来编写代码。专注于其中一个（例如控制器）并暂时将模型和视图视为黑盒。当我从一个大型系统的一个方面转向另一个方面时，我发现自己几乎在“换档”。
In limiting cases investing in program structure may seem like overkill. Would we apply design patterns to a "Hello World" program? Do we need to add comments to it? There are no "Best Practices", there are just "Appropriate Practices in this situation".
Your set up is a minimalist system with a trivial model and trivial relationships - hence MVC could be overkill. The particular features of the application:
Now let's think about one possible change to the application: it's persistent. When you run it tomorrow it restores the state from a database, each time you click a button you need to save the state.
How would you you implement that in your minimalist solution? Now having a common model that knows how to persist itself starts to have value. I'd claim that the MVC structure exactly avoids this turning into spaghetti. It imposes structure, and that structure is a widely used structure that a maintainer would recognised.
I may be reading too much into your question, but it sounds a bit like you are finding it troublesome to navigate an existing MVC application. It's a similar reaction to that which I've seen when someone used to writing small programs hits either a structured or OO program: they get frustrated because there is no single flow to follow, you can't readily see the overall structure. One thing we need to learn to do is to be able to take a Black-Box approach to code. Focus on one this (eg. Controller) and temporarily treat Model and View as a Black_Box. I find myself almost "gear-shifting" as I move from one aspect to another of a large system.