The major problem for me with MVC, is that people build complex applications on an MVC framework and then try to shoehorn various things that are definitely not views, models, or controllers, into the pattern.
I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system).
In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems.
I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there.
However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.
This is why I disagree with the shared language interpretation of design patterns. Once you slap "MVC" or any other name on some code, you'll constantly be second-guessing whether new code is violating the pattern. The goal is to produce working, efficient, secure, maintainable software, not to implement patterns.
I think design pattern books would be more helpful if they deleted all the pattern names and just called the book "A collection of a-ha! moments in C++" or whatever. Readers could skim through the chapters every couple of months until they stop having a-ha! moments. The "patterns" may or may not emerge in the reader's code, depending on what works best for a specific project.
I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system).
In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems.
I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there.
However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.