MVC (Model-View-Controller) is a software design pattern built around the interconnection of three main component types, in a programming language such as PUP, often with a strong focus on object-oriented programming (00P) software paradigms.
The three component types are loosely termed models, views, and controllers. Let’s talk about them individually and then see how they fit together.
The model is where all the business logic of an application is kept. Business logic can be anything specific to how an application stores data, or uses third-party services, in order to fulfil its business requirements. if the application should access information in a database, the code to do that would be kept in the model. If it needed, for example, to fetch stock data or tweet about a new product, that code would also be kept in the model.
The controller is the component that connects models and views together. Controllers isolate the business logic of a model from the user interface elements of a view and handle how the application will respond to user interaction in the view. Controllers are the first point of entry into this trio of components because the request is first passed to a controller, which will then Instantiate the models and views required to fulfil a request to the application. See Figure below:
What are the benefits of MVC?
There is no point explaining what MVC is without knowing why you should use it. MVC is one of the many patterns that will be explained in this book, but to understand the usefulness of this design pattern, we must look toward the problems it helps to alleviate. If you think of a sports team, you might realize that it is essentially a large group of players who fulfil their individual roles in order to drive the team forward. Good sports teams require the effort of each player performing their role to the best of their individual abilities to drive the team forward as a whole.
The Web is an open playing field. It allows businesses, both large and small, to compete against each other without size being a factor in the quality of work. This means many small companies with small developer pools can get the chance to build big web applications. It also means many big companies can have many people working on big web applications at the same time. In all this multitasking and/or group participation, the aspects of an application (which should be separate) often interfere with each other and require more time and effort than strictly necessary to drive forward.
There are many aspects to any complicated web application. There is design, which piques user interest in the product. There is business logic required to do practical things such as process sale items and invoice shoppers. Then there is the continual process of improving, updating, bug-fixing, and general streamlining of the application.
In any unstructured application, these areas tend to melt together in an incoherent mess. When the database needs to be changed to accommodate a new product line or the company decides to rebrand, it doesn’t only affect the code it should. More developers have to get involved to make sure that changes in one part of the application don’t immediately break other parts of the application. Changes that should only affect a tiny section of code end up spilling into all sorts of strange and problematic areas.
This is the problem that MVC seeks to address. It defines strict containers for all of an application’s code and features. When changes to database code are isolated in a model, views and controllers will not break. When an application’s artwork changes drastically, its controller and model will be safe from breaking changes.