Model View Controller is a well known pattern, which was described in the late 1970s. Since then, it is widespread architectural pattern, which influenced many frameworks and applications. For example in Java's well known framework [Spring](https://spring.io/guides/gs/serving-web-content) has element which is called **`@Controller`**, which represents a group of endpoints to handle input. Laravel is a PHP framework which is based on the MVC architecture.

MVC implies separation of concerns, where each element is responsible for a specific role.

**Model** - Model is responsible for managing data, business logic, business rules. Commonly used pattern, Domain Model, perfectly fits into MVC. Model is represented in the user interface(UI). UI in MVC is View.

**View** - View is responsible only for a rendering of a model. It can be a single template or by UI framework (library) rendered HTML. In MVC UI layer must not contain business logic, routing, orchestration, database querying. Only rendering the model representation. All these concerns are handled by a Controller element.

**Controller** - Controller accepts input, queries domain model object from a Model, calls services(notifications, logging, mutates data, queries other data sources). Prepares model for the UI, gets the View element. Combines View with the Model and returns HTML to the user.

Separation of an application code to different elements, has multiple benefits:

- each element can be tested in isolation, without a big effort. You can test your Model and View as a pure function. Model can be a complex component, with thousands of business rules and interrelated domain entities logic. Defining and testing those can become challenging. If you will add another layer of complexity, testing it in the presentation layer, you will lose the ability to test or to maintain tests.

- The concerns are fundamentally different. In enterprise applications, separate roles of employees are developing separate layers. For example business analysts will define the domain and business rules. UI developer will develop UI components/views to render a model. Backend developer will manage input to the controller.

- Having separate View from Model layers provides a possibility to implement different representations for different user groups. For example front office with customers, and back office with the employees working on a product, will have different representation of the Model and different application capabilities.

Since the 1970 pendulum swings from the server rendered application to the client rendered application (SPA, single page application), back and forth. MVC is not always applicable, though it even not always can be applied. This architectural pattern must be used to maintain application complexity. If the application is very small and there is no plans to grow this application, the MVC is a complexity itself, that needs to be managed. The majority of the internet is simple representational pages, created with Wordpress on PHP with a help of UI style utils/components like bootstrap and wordpress PHP plugins. On the other side enterprise application with a terabytes of data and millions of users with myriads of roles/privileges/use cases which you (as a developer/architect) need to handle.

MVC is about the separation of concerns, this means that you need to work hard to enforce it. Enforcing the separation can become challenging. On one hand you have requirements for complex interface, where developer wants to include the domain logic in the representation. On another hand you have a requirement to isolate business/domain logic from the representation. Which is possible, but it can become difficult, if incorrect abstraction is used. This separation can fail if:

- there is not architectural governance in the development process.

- developer will chose the environment, which is know for him. If he needs to switch tools/programming languages/repositories, most likely he will avoid it and mix the concerns.

- tools provided for developers are flexible enough to mix concerns. React with JSX, as an example, is the most powerful templating language for HTML (comparing to mustache, pug or others).

- time constraints are dictating the technical decision.

- current architecture does not support (or the complexity is too high to implement in other environment/tool/place) the required feature to be implemented in the Controller or Model.