Все мы хорошо знаем существующие популярные движки на PHP. Также можно упомянуть практически никому неизвестные, которые разрабатываются любителями. Но всех их объединяет одно большое «НО» в плане идеи, что собственно меня всегда и беспокоило. Почему никто не пользуется CMS при разработке высоконагруженных проектов? Все дело в том, что каждая из них спроектирована таким образом, чтобы всячески мешать разрабатывать какой-либо неспецифический функционал, не говоря о некоторых отдельных ситуациях.
Идея эта у меня появилась так же давно, как я начал программировать. С тех пор много лет прошло, много опыта набрался, практики. В общем, есть с чем сравнивать. Почти идеальным примером для меня является Django на Python'е. Но для конечного пользователя требуется огромное время для шлифовки интерфейса, базовых функций и прочего. И я подумал: не лучше ли мне писать ядро системы и прочее, под чутким руководством публики, которая предоставит максимум конструктивной критики в пользу моих наработок?
Базовые шаблоны программирования
Наиболее распространенным шаблоном программирования, по моему опыту, на данный момент является MVC и его модификации. Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия. Нельзя так просто взять и разделить все на Model-View-Controller. Конечно, я могу ошибаться, и собственно потому вы это читаете.
Возьмем за пример простую работу с API и синхронизацию с данными модели к примеру User. За движок, фреймворк (кому как удобно) — Symfony. Я уверен: опытные в этом деле люди уже поняли с чего все начнется и чем все закончится.
Мою альтернативу я не могу назвать идеалом, но мне она очень по душе. Суть сего такова, что любые операции с данными системы, вычисляемыми данными, данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP с классами и собственным пространством имен. Но кто мешает нам положить туда файл конфигураций, базовые шаблоны части View или кешируемые данные? Ведь все эти вещи относятся именно к нему, и стоит ли нам засорять общую папку для шаблонов/конфигов?
- Доступ к базе данных будет иметь только Service / Сервис
- Сервис может содержать классы, трейты, Конфигурационные и кеш-файлы, базовые шаблоны
- Доступ к сервису будет осуществляться с помощью единого метода объекта из области контроллера
- Сервис обязательно имеет собственное пространство имен
Такое решение значительно упрощает модуляцию всей системы. Когда ваш контроллер вообще не имеет доступа к базе данных, потребуется редактировать, к примеру, трейты сервиса, чтобы получить необходимые данные. Но с другой стороны, это очень поможет организовывать правильно код и не мешать одно с другим.
Если хорошенько подумать, то это — тот же самый MVC, только здесь роль модели выполняет наш Service, который, как мы видим, значительно отличается от устоявшихся стереотипичных ОРМ моделей.
Как результат, фасадный класс сервиса User может в себя вмещать работу с его локальными данными, собственными файлами на сервере, работу с API и прочее. Унификация такой большой области разработки дает возможность очень качественно реализовывать конечный результат.
Очень хотел бы узнать ваше мнение.

