When I say MVC, I mean the pattern, and not the ASP.NET MVC tool.
There seems to be an ongoing (more like a never-ending) argument pertaining to major drawbacks of the pattern.
MVC is a pattern that has some differences with other patterns.
To start with, I should call MVC an architectural pattern, and not just a design pattern.
MVC is an architectural pattern simply because it defines the structure of an entire application, while design patterns only take care of some responsibility within an application.
The aspect that defines the character of MVC is Separation of Concerns. It clearly identifies the main concerns in an application: Presentation, Interactions with the actors, CRUD operations on business objects and other application objects.
Any application, large and small, has to take care of these responsibilities, so, MVC could and should be applied on all types of applications. The point is how it is applied on small apps and how it is applied on large apps.
The key is scope. Let’s consider a console application as an example of a small app, like for instance, a command-line tool like grep.
It has presentation (presents the results of its analysis on screen as a stream of characters), interactions with the actors (through command-line switches), and it has CRUD operations on business objects and other application objects (searches for files, scans the contents of the files that match search pattern and analyzes lines in its content that match the target regular expression, then, lists results to present).
To be able to design a tool that could be maintainable, it would make sense to use MVC to separate the aforementioned concerns of this app.
The original grep tool was designed and developed in C, and there would be no major problems to use MVC with a C application. In C, we have structs, pointers, pointers to functions, dynamic memory allocation, release of resources, etc.
The main application execution loop should talk to the three concerns, the Model, the View and the Controller, and the concerns should talk with each other as the pattern indicates. They should use events (callbacks based on function pointers) to talk to each other asynchronously.
Each concern should have its own set of helper functions that would take care of specific responsibilities (parse command-line switches, search files that match search string, scan file content line by line, compare line text with regular expression, compile list of results).
As we can see, if we can apply this architecture in C, we can certainly apply it to any other modern programming language like Java or C#.
On a larger application, we would still have the three concerns talking to each other in a similar fashion, but we would have more internal structures, components and layers to take care of, as a larger application will also have to take care of many other quality attributes, like scalability, availability, security, etc.
As briefly shown by my comments, the key is the scope. If you wisely use scope with your implementations of MVC, there is no way that you will misuse it, abuse it, or otherwise face drawbacks.
Kind regards, Gastón