[arximboldi]

Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.

I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:

https://github.com/arximboldi/lager/issues/1#issuecomment-34...

[whitefish]

Sorry, that’s not making sense. In the MVC I am used to there’s only one controller active at one time and that controller owns the entire screen.

[arximboldi]

We were precisely talking about composition and now you say there is only one? I guess you are talking about small apps where you have small dedicated views?

That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...

Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.

In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).

But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.

[interlocutor]

@arximboldi, I wouldn't use MVC for implementing something like Photoshop or and IDE, that's not the kind of application MVC is good for. MVC works well for applications that navigate through multiple screens.

[lsdafjklsd]

Yea basically this. Built a 'big data app' using Ember, which was all well and fine until some of the routes essentially became their own apps, that were more akin to apps like photoshop. MVC really broke down for us here, and it wasn't until we introduced react / redux and slowly refactored the application until things got more manageable and sane.

[Scarblac]

In the original Smalltalk MVC pattern, every single element of the UI had its own model, view and controller.

Since then a lot of different things have been called MVC..

[beaconstudios]

OOP was very different in smalltalk too. Industry software dev has really strayed away from the theoretical origins it was based in, although I think the tide is starting to turn back now.