I am wondering about this. I have now for a while been interested and played with - though admittedly also a bit frustrated, given that some of the most knowledgeable seeming posts here were very hard to understand as they involved a lot of extra jargon that I was not familiar with at the time, namely ones like these:
How should a model be structured in MVC?
in describing it, though that could be due more to my coding background as being much more in the desktop and mobile sphere than the Internet/web sphere (but then it would be better to have a similarly informative post "translated" to that context or even better that's just more conceptual and more detailed in explaining what all the concepts like "domain objects", etc. as MVC is a very broadly applicable pattern) - the "Model-View-Controller", or MVC, pattern of laying out a piece of software which, I understand now in the following way:
- The software is composed of three "layers". The highest-level layer is the model layer, or "business logic" layer. This is where all the "nuts and gears" of making the stuff the program is supposed to make (e.g. like in a computer game, this is where all the gameplay logic would go) happen. The other two layers are the data layer and UI layer; and these are in charge, in effect, of converting the model layer to system output, respectively to permanent storage and to the user interface peripherals of the computer (e.g. the screen, the keyboard/mouse/touchpad etc.).
- The model layer is separated in fours: domain objects, which contain the actual business logic, data mappers which abstract access to the persistent storage (which could be a database, such as Android's Room Persistence Library [SQL wrapper], or, say, the file system as in the desktop/server space), repositories which hold the data mappers and provide a "library"-like interface where you can, say, look up and grab a domain object by a key (e.g. "findSomething()" methods), and services which are the interface between the model layer and the UI and data layers.
- The UI layer is separated into View and Controller components, where that View components take over presentation of model layer data to the user and Controller components take over mutation of model layer data; that is, they send commands to the Services in the model layer which have side effects. It is from this, and the existence of the Model layer, that the name of the whole pattern arises.
My question concerns the last part of the pattern in relation to modern GUI systems - which includes mobile as well as desktop, e.g. Android (I have zero experience with Apple because of not having the money). In particular, it seems to me that a logical way to achieve this (if I have that part right - as I said, these posts tend to be very hard to understand as not only do they involve all this specialized jargon but also the explanations I try to look for online for them are similarly opaque) is to suggest that Views should be associated with GUI widgets that are responsible for displaying model state, while Controllers should be associated with those that the user will interact with to cause things to happen (which in most cases means something must happen in the model layer).
The problem, though, is that in modern GUI systems that seems quite hard to arrange, because of how much they commingle such things - one of the more egregious examples being, say, the main widget of a document editor, which fuses editing and display responsibilities into a single element of the GUI, so that it must both change and display the document held (presumably) in the model layer. Moreover, which controller widgets may be displayed can in turn depend on the state of the model layer, as some functionality may or may not be available in certain states and we may want the UI to reflect that, which seems like view (presentation) functionality. (Think buttons being greyed out or not depending on whether a given functionality is accessible or makes sense in a given model state.)
If one is using a pre-made widget system, as is supplied with virtually all GUI systems, what are the best practices for keeping the concerns underscored by the View (access) and Controller (mutation) as separate as possible when it presents you with such a fused interface? Finally, where exactly does creation of things like the windows that hold these often-mixed widgets go? Is that in the view, controller or some other part of the UI system that is outside the MVC schema of categories?
Or is there yet more of something I have missed here, as seems quite likely given what I mentioned earlier about finding the existing materials rather difficult to understand?
(I'd also add a remark that, if anything, it seems easier to fit the related MVVM pattern [model-view-view model] to modern GUI systems as they don't make that access/mutation split; but it also seems like that the choice of organizing pattern should not depend on the specific UI framework you intend to target, as that kind of defeats the purpose. Indeed, Android seems very suggestive that it 'wants' an MVVM pattern by providing something called ViewModel in addition to its Fragments and Activities which would be the Views of MVVM who are not bound to this same separation of accession elements from mutation elements. Nonetheless, for me, the access/mutation split seems logical and what I'm asking about is just how can you pull it off in these systems.)
