При разработке разных по масштабу приложений становится все более интересно применять различные подходы к проектированию веб приложения. В последнее время особо остро встал вопрос о разделении логики в большом проекте, базирующийся на MVC шаблоне проектирования.

Сущности и сервисы

Сущности

Поскольку задачи стали более сложные и комплексные, а данные в БД хранить все невозможно, то было принято решение о создание сущностей статичных данных в проекте. Суть простая — в определенном месте хранятся базовые статичные данные, которыми можно оперировать в PHP коде, а в БД заносятся их англоязычное представление.

В базовом представлении класс Entity.php может иметь следующий вид:

declare(strict_types = 1);

namespace entities;

class Entity {
	protected static $map;
	
	public static function getMap():array {
		return static::$map;
	}
}

Наследники его должны реализовать свойство $map, которое будут получать следующим образом:

E1::getMap();

Причем, большинство статичных данных будут удовлетворять логике получения. Если требуется группировать данные или выделить дополнительные, то это логика реализуется уже в классах наследниках.

Сервисы

Сервисы предназначены для хранения бизнес логики приложения. Помимо этого, сервисы можно использовать как логика отдельная от фреймворка. Сервис — это набор методов, который реализует логику приложения. Условия, которые были определены сервису:

• сервис не должен самостоятельно обращаться к контроллерам и представлениям;
• сервис может обращаться к базе данных, моделям и сущностям.

В лучшем случае, контроллер должен передавать сервису все необходимые данные, но может возникнуть такая ситуация, что ему потребуется самостоятельно обратиться к какой-то модели, чтобы получить данные. Ничего страшного в этом нет, но лучше придерживаться логики, что маршрутами данных оперирует контроллер.

По умолчанию сервис не реализует никакую стандартную логику, поскольку является уникальным исполнением части проекта. Поэтому, было принято решение, что базовый класс сервиса не будет создан. Хотя, стоит отметить, что базовые классы лучше создавать, даже если они будут пустыми. Это объясняется тем, что может наступить такой момент, что всем наследникам надо будет иметь одинаковую логику или выполнять какой-то метод. Чтобы не производить во всех классах изменения в области наследования, проще изначально сделать наследование от базового класса, в котором реализовать данную ситуацию куда менее сложнее и дешевле в области временных ресурсов.

В общем представлении поток данных в предлагаемой архитектуре можно представить следующим образом:

1. Данные или запрос поступает в контроллер.
2. Контроллер общается с моделью, сервисом и сущностью в двунаправленном порядке. Тут он получает и отдает какие-то данные.
3. Сервис отдает данные в контроллер, получает или отдает данные в модель.
4. Контроллер отдает полученные данные в представление.

Таким образом, получается, что данные и принцип работы приложения распределен между базовыми элементами MVC и новыми.

Заключение

Стоит отметить, что внедрение такого подхода позволило значительно упростить разработку приложений и контролировать поток данных. Большинство данных были вынесены из базы данных, что позволило сократить ее объем и увеличить общую скорость приложения за счет уменьшения количества запросов.