In the referred paper the Controller sends messages to the View but never interacts with the Model, so the diagram in the article incorrectly represents that concept.
MVC Isn’t MVC
21–30 of 165 posts
Re: MVC Isn’t MVC
#22convoluted nonsense
Re: MVC Isn’t MVC
#23What MVC refers these days is not of MVC from 1979 but from the Design Patterns by Gags of Four and they did not mean the patterns should be applied strictly as is. So.. what? What is the point of the article? He does not seem to really understand the purpose of design patterns and it in practice
Re: MVC Isn’t MVC
#24Responsive UI-driven apps these days use MVC backend => frontend MVC app context loader => frontend MVVM application layer. https://learn.microsoft.com/en-us/dotnet/architecture/maui/m...
MVVM uses two-way data binding. By now it is widely acknowledged that one-way data binding is better.
I wish I was smart enough to understand what this really means, I often feel very much like a code monkey when these discussions come up.
Re: MVC Isn’t MVC
#25For OpenStep/NeXTSTEP style MVC, which is very similar to the original MVC, is well explained in the book "OpenStep for Enterprises", https://www.amazon.com/OpenStep-Enterprises-Nancy-Knolle-Cra... . I just cannot understand why the author says it's different from ST80 style MVC.
Re: MVC Isn’t MVC
#26Earlier quoted context omitted.
MVVM uses two-way data binding. By now it is widely acknowledged that one-way data binding is better.
I wish I was smart enough to understand what this really means, I often feel very much like a code monkey when these discussions come up.
In the old days there was just MVC. Then Microsoft announced successor to Windows Forms... a new technology called WPF. WPF uses MVVM which automated more of the work that a developer has to do: it automatically updates the UI when data objects change, and it automatically updates data objects when the user inputs something through the UI. Sounds cool, right? The problem is that in large projects it becomes hard to understand how data is flowing. Because of excessive automation things are happening behind the scenes. Developers began to understand that this is not as cool as it initially looked. React re-introduced one-way data binding, which updates the screen when data objects change, but not the other direction. People found that they are significantly more productive with this technology even though it does less on behalf of the developer. Now it is widely acknowledged that one-way data binding is better.
Re: MVC Isn’t MVC
#27Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…
We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time.
Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.
Re: MVC Isn’t MVC
#28Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…
> My take on the model layer is : write everything that’s not strictly specific to your UI there.
My take is this, except with the caveat that the larger a model gets, the closer to declarative it should become. You touched on this by saying the model layer rather than just the model, but it's worth emphasising.
You can achieve this by abstracting out the messy bits, e.g. moving some hooks to a task queue (processing an image) and others to a declarative helper (validation as a schema instead of functions), turning a massive querybuilder jumble on one model into a library that lets you declare valid search and ordering by fields and operators for all models, etc. When a model becomes too big to fit in your editor window is probably a good time to start getting rid of most of its procedural code.
One of the old Rails aphorisms was (and may still be) "fat models, skinny controllers", and while this was better than the alternative it still led to a lot of 500-line monsters.
Re: MVC Isn’t MVC
#29Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…
We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.
Lol, but MVCSR (MVCaeser) sounds like an architectural dictatorship where one must follow all rules or else be outcast from citizenship. Where some executive will stab you in the back and sell it to a private equity firm to be cut and squeezed by all the lands and your intentions and beautiful code structure is murdered by junior bootcamp devs. /s
Re: MVC Isn’t MVC
#30Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…
The end of this rabbit hole is probably something like “actually DDD is best!” or whatever comes/has come after DDD (domain-driven design)