I know, MVC stands for Model View Controller. Its neither a technology nor a programming language. Its an architectural pattern commonly used for developing user interfaces that divides an application into three interconnected parts. ...
Is it necessary? Without it any performance issue?
Top comments (7)
it is a good separation of concerns, you don't need a specific tool to make an MVC app (although there's plenty of them...), the point is by separating where your data comes from, how you present it and the glue between them separately you make an application that's easy to debug compared to a monolithic model
There is no performance issue? A MVC app and without MVC are same in loading and fetching data
That’s not a straight answer unfortunately, there’s a lot of different tools and languages for MVC applications. Writing your own application as vanilla as possible is not as straight forward either, and even when it does work you’ll also have to make it scale. Giving the best chance to both ends, a fast and scalable MVC app on a framework, say Rails, and a vanilla JS application written as effciently as possible the only difference would be the amount of work you’re gonna put in, just MHO
MVC is just one architectural pattern you could use. A critique of MVC is that reusability is difficult to achieve. Another critique of MVC is the paradigm locks engineers into a way of working that isn't applicable for every situation when developing applications. For UI development, MVC provides a good separation of concerns for the task it's supposed to achieve: binding a data model to the view.
With or without MVC, but speaking in the parlance of MVC, performance is probably impacted by the functions that bind the "model" to the "view" or the methods that transform the model. How any paradigm implements binding a data model to the view is of great importance for performance. How complex types are iterated upon could contribute to performance issues in any paradigm. Security is also of concern, as there could be potential exploits lurking in some implementation.
MVC had its start in server side rendering. The controller was the entry-point of the HTTP Request (Get or Post) and would, in turn, populate a model (with data), and finally bind the now filled model to the View Template sending back the View with data embedded into HTML statements.
Early Angular did the same thing but on the client side. AngularJS as it was known was a big hit only because of the binding concept. (It had other major architectural flaws).
Today Angular doesn't use the controller rather it uses a router configuration to pass the inbound request (with data or not) to the proper component. The component then only has a View Template, CSS and binding to models of the data.
A little biased, but the guys at Vets Who Code did a good podcast on this.
youtu.be/bP2m8i11WGM
Let me check