模型视图控制器（MVC）设计模式 - 如何将多个视图链接到多个模型？

Question

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 :)

Answer 1

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:

1. There is no interesting model. Incrementing one value has no effect on any other value.
2. There is no interesting control requirement. Pressing one button does not cause any state change other than to the immediate button.
3. This sounds like a throw-away program with no future maintenance requirements.

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.