I am writing CMS in PHP. Part 1

Immediately I want to moderate your ardor in relation to the headline: I have survived the school age for a long time and I know what I'm talking about. So let's be tolerant of each other and give me the opportunity to present my idea before you criticize it.

We all well know the existing popular PHP engines. You can also mention almost unknown to anyone, which are developed by amateurs. But all of them are united by one big “BUT” in terms of ideas, which actually always worried me. Why no one uses CMS when developing highly loaded projects? The thing is that each of them is designed in such a way as to interfere in every way with the development of any non-specific functionality, not to mention some individual situations.
This idea came to me as long as I started programming. Since then, many years have passed, a lot of experience gained, practice. In general, there is something to compare. An almost perfect example for me is Django in Python. But the end user needs a lot of time to polish the interface, basic functions, and more. And I thought: isn’t it better for me to write the kernel of the system and so on, under the strict guidance of the public, which will provide maximum constructive criticism in favor of my achievements?

Basic programming patterns

The most common programming pattern, in my experience, is currently MVC and its modifications. Many times I tried to write, following the pattern, but the result always drove me crazy. You can’t just take and split everything into a Model-View-Controller. Of course, I could be wrong, and that's why you are reading this.

Let us take as an example simple work with the API and synchronization with model data, for example, User. For the engine, the framework (which is convenient for anyone) - Symfony. I am sure: experienced people in this matter have already understood how it will all begin and how it will end.

I can’t call my alternative an ideal, but I really like it. The essence of this is that any operations with system data, calculated data, data of other services are positioned as a Service. The service is essentially a regular PHP package with classes and its own namespace. But who is stopping us from putting the configuration file there, the basic templates of the View part or the cached data? After all, all these things relate specifically to him, and should we clog the shared folder for templates / configs?

  • Only the Service will have access to the database
  • A service may contain classes, traits, configuration and cache files, basic templates
  • Access to the service will be carried out using a single object method from the controller area
  • Service must have its own namespace

This solution greatly simplifies the modulation of the entire system. When your controller does not have access to the database at all, you will need to edit, for example, the traits of the service in order to get the necessary data. But on the other hand, it will help to organize the code correctly and not interfere with one another.

If you think carefully, then this is the same MVC, only here the role of the model is played by our Service, which, as we see, is significantly different from the well-established stereotypical ORM models.

As a result, the facade class of the User service can contain work with its local data, its own files on the server, work with the API, and more. The unification of such a large area of ​​development makes it possible to very efficiently implement the final result.

I would really like to know your opinion.

Also popular now: