Talk about MVC and web application architecture

MVC pattern has long been on the market, but many use it in different ways.

What is the problem? The fact that many developers complicate the code very much and then it is expensive to maintain and develop, or you have to do global refactoring, which is not quite profitable for a business.

The main goal is to complete the project in time and further develop it by investing in the planned budget.
')
One of the important criteria for the quality of a code is its simplicity. But how to measure simplicity? One option is to calculate the number of elements of the system. The smaller elements, the easier the system.

Suppose business logic can not be done less, because it depends on the business, and not the programmer, except that you can optimize it. Then the criterion will be - the number of code is NOT business logic. With development experience, we saw that it is very convenient to divide MVC in this way:

Core Components
Server Environment needs
Routing
Common Libraries
M (Controller can connect with different objects):
2nd layer of business-logic
Get Set, Data processing
HMVC Contollers
Adapters (for easy work with other services)
V = templating, head, footer-scripts, parts
C = easy code
+ L = Libraries (for advanced and third-party components)

Many people understand the model as working with data and this can be either getting data from the database or a whole internal service or assembling an MVC component for insertion into the view. It is desirable that they are NOT strongly connected and the code can be easily extended.

View in web development often carries headings headings and scripts that are not already an appearance, but carry a separate meaning. It is better to transfer them to separate files. Also View-ki should be easily divided into parts for ease of scaling the project.

The controller is the main element of the whole bundle. It is the distribution of reactions to customer requests. And often, at the first stage, this distribution is performed by Rotuting, and only then in the controller method all the necessary data is collected and placed in the View.

We consider this architecture optimal. Each direction can use OOP, inherit abstract classes and become more complex, but it is important to keep boundaries so that the code can be easily expanded and convenient for collective work.

Many frameworks support this architecture, and many accurate developers build programs like this.

If, however, the elements discussed above are mixed up in the code, then we recommend refactoring as soon as possible, and the development process after that can be significantly accelerated.

Thanks for attention.

If anyone knows other good options for architecture, please write in the comments your opinions, thank you.