5 ms·

Something bothers me about all this MV* pattern stuff. It's the notion that there is this canonical great pattern applications should follow. There's also a lot

Something bothers me about all this MV* pattern stuff. It's the notion that there is this canonical great pattern applications should follow. There's also a lot of "we" involved in this, and social posturing of "best practices". Look if MVWhatever works for your particular problem, knock yourself out, but I've seen so many badly designed applications because they tried to hammer something into an MVC framework without considering if any of that actually made sense for what their application does. And if you suggest that all this scaffolding is just hiding a more elegant design, you're going against "best practices" (despite the fact that most of these "best practices" arise from opinionated bloggers.) I feel like MVVM is generally solving the wrong problem though. Ok, so MVC tends to get nasty because people shove all the logic into the controller, the model ends up being a crappy interface to the database, and views do too much. But maybe that just means that MVC is a bad fit for what you're doing. It doesn't mean "we" need the "next" MVC, it means you have to do the hard work of actually designing what your application does without training wheels.

Aleman360 11y ago
It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. Also helps in large organizations that develop lots of apps because it reduces the learning curve for new team members. Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph.
- overgard 11y ago
  > It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. That literally applies to any program though. A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). > Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph And yet there's like 500 blog posts about why you're doing it wrong, and how to do it better, etc. Of course, in truth it's not complicated, what makes it complicated is when it's applied in contexts that make little sense.
  - Arnavion 11y ago
    >because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much coupling between them except to pass data back and forth. Sounds like a regular compiler to me.
    - overgard 11y ago
      You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. Just looking at what you said though: why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Also, claiming the view as input/output is pretty reductive. How do I represent a lexer as a view? More importantly, why would I want to? Fun experiment, find the views and controllers in here: https://github.com/llvm-mirror/clang https://github.com/llvm-mirror/clang
      - Arnavion 11y ago
        >You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.
dietrichepp 11y ago
I think MVVM mainly makes two things easier: refactoring models and testing the user interface. It's not going to be a good fit in places where MVC wasn't already a good fit.

Aleman360 11y ago

It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. Also helps in large organizations that develop lots of apps because it reduces the learning curve for new team members. Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph.

overgard 11y ago
> It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. That literally applies to any program though. A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). > Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph And yet there's like 500 blog posts about why you're doing it wrong, and how to do it better, etc. Of course, in truth it's not complicated, what makes it complicated is when it's applied in contexts that make little sense.
- Arnavion 11y ago
  >because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much coupling between them except to pass data back and forth. Sounds like a regular compiler to me.
  - overgard 11y ago
    You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. Just looking at what you said though: why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Also, claiming the view as input/output is pretty reductive. How do I represent a lexer as a view? More importantly, why would I want to? Fun experiment, find the views and controllers in here: https://github.com/llvm-mirror/clang https://github.com/llvm-mirror/clang
    - Arnavion 11y ago
      >You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.

dietrichepp 11y ago

I think MVVM mainly makes two things easier: refactoring models and testing the user interface. It's not going to be a good fit in places where MVC wasn't already a good fit.