Bitrix, HMVC and a bit of nonsense ...

Hello! Surely many people know what CMS Bitrix is, what it is and what kind of “wonderful” code and architectural solutions its developers represent. In this post I would like to offer a new vision for the development of components and modules of the system.

HMVC

Before explaining what these 4 letters are, let me remind you what the last three mean:
')


MVC itself is a design pattern that divides the system into three parts:

• Model - business logic;
• Controller - control / interaction logic;
• Presentation - UI.

The advantages of this template are that if it is normally implemented, then the business logic is completely independent of C and V. Who needs the details and who for some reason still does not know what it is - go ahead to google.

It seems to be all right, MVC is almost a panacea (this is the kind of thing that solves all the problems), but if the system is large enough, then it will inevitably become more complicated and as a result (or cause) problems of scaling arise. Here a good friend comes to the rescue: H - Hierarchical .



The main idea of ​​this template is that the whole system is divided into separate, independent triads (MVC's), which communicate with each other through controllers. Thus, business logic is still isolated from the outside world, and in fact the system spontaneously splits into small parts, and this is much more convenient and easier for spaghetti-dependencies that will inevitably arise in a large system.

Triad communication occurs by querying the controllers. The following types of requests can be distinguished:

• external request - creating a request to another server (divine distribution);
• internal request - creating a request to the current server;
• a function call is simply a call to the controller's action from the code, without additional request to the server.

Bitrix and his cockroaches

Bitrix is a highly advertised and extremely unfriendly management system for a developer. But in fact this is not the case, so let's get down to business.

According to the authors, this system implements the MVC pattern. It looks like this:



Um ... seriously? The model is located in another structural part of the system, separately from the controller and the presentation. Separately, Carl !!!

In fact, this is quite a good move, because the whole system is based on components and each of them can pull any model, any module, and to be exact a specific model - information blocks. But as for me from the point of view of MVC, this is wrong, the controllers are overloaded with logic (at least if you look at the implementation of standard components).

Bitrix Models

Information blocks - this is a very convenient and flexible solution for storing information, you can not argue and ignore this tool - it's silly. For clarity, the structure of the system in general can be represented as:



Looking at this picture, we can conclude that the decision to separate the model is pretty damn wonderful. But in this case there is a lot of logic in the controllers (components), and models (API) are just a domain model , and they do not contain any logic.

Bitrix Controllers

Bitrix assures us that the components play the role of controllers, but I do not agree with that.

Components are widgets: they receive input data and in some way convert them.

Complex components are controllers (more precisely, front controllers): they take the user's request as input, parse it and initiate the requested action. Schematically, this can be expressed as:

Bitrix HMVC

We got acquainted with the bitrix about MVC, now let's consider the options for communication between the controllers (components) with each other.

As the documentation advises us: components can be communicated either through global variables or through events. In fact, these are tips on cooperation of the modules, but strictly speaking, they are also applicable to the components, only they do not quite fit:

• global variables - implicit data transfer;
• events - generally past the box office.

So, in my opinion, the transfer of parameters by reference is optimal:

<? $APPLICATION->IncludeComponent('comp1','',[& $params]); $APPLICATION->IncludeComponent('comp2','',[$params]); //        $APPLICATION->IncludeComponent('comp1','',['request' => $req, 'response' => & $res]); $APPLICATION->IncludeComponent('comp2','',[$res]); ?> 

Everything is transparent and understandable where and when it comes.

It seems to be all, but no. Each individual component (not complex) must be a separate MVC triad, and this is strictly not. Service layer comes to the rescue:



Due to this structure, each component (not complex) has its own model (service layer), with the necessary business logic, which in turn refers to the API (domain model) to work with the database.

A little nonsense

Of course, it would be possible to finish the article with the paragraph above, but my emotions rush out, so I cannot be silent. I am very amused by the fact that all bitrixsoids, regardless of their level of professionalism, shout in one voice “use everything out of the box, if this is not in the box, do not use the bitrix at all!”. The question is "Why then the marketplace?", But oh well.

Are you guys serious? Are you a developer or what? I understand that Bitrix is ​​a certain constructor (guess whose opinion is this) in which there is A LOT of what it is, but just a moment: a lot is NOT ALL . And I feel sad when Bitrixoids say they use standard modules and on the basis of them do something.

I do not call to rewrite all modules and sculpt a bunch of bicycles (although the marketplace is replete with them). Of course, it’s worthwhile to write a pair of bicycles to upgrade a skill, but from standard modules you can take only an API and no more, because in real life I haven’t seen worse govnokod, but this is Bitrix, there's nothing to be done about it.