I've been reading up about Model View Controller, Model View Presenter, Model View ViewModel, and so on, and generally, the underlying concept seems pretty simple to understand: keep the pretty visuals and sciencey guts as separate and ignorant of each other as possible. No getting the logic peanut butter in the design chocolate; cool, I like that.
The problem is I'm still a bit fuzzy as to that third part... the not-model-or-view one. Everyone seems to have their own idea of what to call it, what it should do, what's proper, what's just plain wrong... and I'm going nuts trying to figure out when a Presenter becomes a ViewModel and when a View shouldn't be doing that because that's the Presenter's job and--
Rather than asking for someone to explain the difference between them--because that's already been done time and time again (I know; I've read more articles than I can count)--I'd be curious to hear the thoughts of a few programmers on the model I've cobbled together myself.
That said, what would you classify this design as, and perhaps more importantly, do you see anything about this that obviously sucks? Sure, I'd love to hear I'm doing good if this truly is solid design, but I'd much rather be given solid advice over praise.
Note: I'll be using "the Bridge" for the mysterious third part of Model-View-? to avoid any subconscious suggestions of what it "should" be.
- Is the authority on data.
- Receives information about requested changes from the Bridge.
- Contains and performs all logic for how data relates to other data.
Informs the Bridge when data changes (for data the Bridge has expressed interest in).Wording edit: Allows outside subscribers (about which it knows nothing) to monitor it's state or calculation results.
- Has zero knowledge of the View.
- Is concerned with providing the user a way to view and manipulate data.
- Receives information about data updates from the Bridge.
- Contains and performs all logic for how to present data and controls to the user.
- Informs the Bridge when the user has performed an action that (possibly) affects the Model.
- Informs the Bridge what information it's interested in.
- Has zero knowledge of the Model.
- Is the coordinator and translator between the Model and the View.
- Makes any appropriate formatting changes to information being passed between the Model and the View.
- Retains information on "who needs to know what".
- Has knowledge of both the Model and the View.
- In more complicated programs, it's common for there to be multiple Models. In this situation, the Bridge typically takes on the job of coordinating/translating between the multiple Models, and thus becomes the authority on what protocall/API/design Models should be built to. (e.g. if building a card game program, and you want to build an alternate deck shuffling model, you should use the Bridge for determining what functions are required for properly communication with the Bridge.)
- In small simple programs with only one View and Model, it's common for the Bridge to "assume" what functionality is available on either side. However, as programs become more complex, it's recommended that the View(s) and Model(s) report their functionality to the Bridge so that it can avoid inefficiencies and buggy assumptions.
I think that just about covers it. By all means, I welcome any questions you might have about the design I tend to use, and I likewise encourage any suggestions.
And as always, thank you for your time.