4 ms·

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases. Disagree. There is no reason to believe MVC tends towards spaghetti in

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases. Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.

dceddia 9y ago
It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction. I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.
beaconstudios 9y ago
the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.
arximboldi 9y ago
I disagree. It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice. What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs. It is way simpler (and less!) code in all but the most trivial of the examples.
- whitefish 9y ago
  If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
  - arximboldi 9y ago
    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-345453385 https://github.com/arximboldi/lager/issues/1#issuecomment-34...
    - whitefish 9y ago
      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.
      - interlocutor 9y ago
        @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.

dceddia 9y ago

It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction. I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.

beaconstudios 9y ago

the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.

arximboldi 9y ago

I disagree. It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice. What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs. It is way simpler (and less!) code in all but the most trivial of the examples.

whitefish 9y ago
If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
- arximboldi 9y ago
  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-345453385 https://github.com/arximboldi/lager/issues/1#issuecomment-34...
  - whitefish 9y ago
    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.
    - interlocutor 9y ago
      @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.