SLOT-H: Принципы работы
Ядро и модули
Ядро
Ядро - это основа системы. Оно отвечает за:
- Маршрутизацию запросов (Router, Request)
- Автозагрузку классов (Autoloader)
- Работу с базами данных (Database, DbEngine, Select)
- Базовую ORM (Model)
- Шаблонизацию (View)
- Контроллеры (Controller, ApiController, CliController)
- Конфигурацию (Config, CC)
- Кеширование (CacheAbstract)
- Очереди (Queue)
Ядро не знает о том, какие модули существуют. Оно предоставляет инструменты, но не содержит бизнес-логики.
Ядро находится в папке `Application/Assistance`.
Модули
Модули - это надстройки над ядром. Каждый модуль решает свою задачу.
Структура модуля:
Modules/
└── ModuleName/
├── Bootstrap.php # Загрузка модуля
├── Crud.php # Права доступа
├── Preloader.php # Предзагрузка (авторизация)
├── Controllers/ # Контроллеры
├── Models/ # Модели данных
│ └── DbTables/ # Описание таблиц
├── Public/ # CSS, JS
│ ├── css/
│ │ └── Project_1/ # Стили для проекта 1
│ └── js/
│ └── Project_1/ # Скрипты для проекта 1
└── Views/ # Шаблоны
└── Project_1/ # Шаблоны для проекта 1
Модули могут быть добавлены, удалены или заменены без изменения ядра. Исключение составляет модуль Base - он является неотъемлемой частью экосистемы и не может быть удалён.
Как это работает
1. Запрос приходит в `index.php`
2. `Router` инициализирует объект `Request` (объект запроса) и определяет, какой модуль и контроллер вызвать
3. Загружается `Bootstrap` модуля
4. `Preloader` проверяет права доступа
5. Контроллер обрабатывает запрос
6. Модель работает с базой данных через `DbTables`
7. `View` рендерит шаблон из папки `Views`
Базовые модули
- Base - пользователи, роли, права, очереди, логи, константы. Неотъемлемая часть системы.
- Free - публичная часть, главная страница, статические страницы.
- Geo - страны, города, языки, валюты, часовые пояса.
Новые модули создаются по той же структуре и подключаются автоматически.
Модели
В системе применена парадигма, при которой контроллер не знает, с какой моделью он будет работать. Это позволяет контролировать процесс в любой момент времени.
Программист в коде экшена явно вызывает нужную модель через статический метод. Контроллер не содержит автоматической привязки к модели и не наследует её. Модель подключается только тогда, когда это необходимо, и только та, которая нужна в конкретном экшене.
Это даёт возможность в одном контроллере работать с разными моделями, а также легко подменять модель без изменения контроллера.
Сравнение с общепринятыми стандартами
В традиционных MVC-фреймворках (Laravel, Symfony, Yii) модель обычно жестко привязана к контроллеру через объявление в конструкторе или через систему внедрения зависимостей. Контроллер знает, с какой моделью он работает, и вызывает её методы напрямую. Замена модели требует изменения контроллера или использования сложных механизмов конфигурации.
В данной системе модель не привязана к контроллеру. Контроллер ничего не знает о том, какая модель будет использована. Программист сам решает, какую модель вызвать в каждом конкретном экшене.
Преимущества такого подхода:
- Контроллер не привязан к конкретной модели. Один и тот же контроллер может работать с разными моделями в разных экшенах или проектах.
- Модель можно переопределить для конкретного проекта без изменения контроллера.
- Логика работы с данными не дублируется в контроллерах. Она централизована в моделях и базовых классах.
- Упрощается тестирование, так как модель можно подменить в любой момент.
- Код становится более читаемым и предсказуемым - программист всегда видит, с какой моделью он работает.
В традиционных подходах для переопределения модели обычно требуется создавать новый контроллер или использовать сложные механизмы dependency injection. В данной системе это решается на уровне соглашений о именовании.
Что дальше?
- ➡️ Раздел 06. Архитектура
- ➡️ Раздел 07. Автолоадер
- ➡️ Раздел 08. Соглашение о хранилище данных