Получи случайную криптовалюту за регистрацию!

Как мы готовим MVC в Ларавеле Мы активно используем Ларавель, | Коля Митин говорит

Как мы готовим MVC в Ларавеле

Мы активно используем Ларавель, потому что один и наших ключевых продуктов написан на нём. Ларавель — стройный MVC-фреймворк, с достаточно хорошей документацией. Тем не менее, есть некоторые особенности, которые мы привносим в парадигму разработки на этом фреймворке.

Пойдём от противного, чтобы показать, как мы используем MVC, то есть покажем ситуации, где можно написать код не в той части системы. Иными словам, как код случайно не в то место.

Сверху пирамиды у нас представление. В Ларавеле представления делаются на шаблонизаторе blade.
Симптомы протечки лишнего кода внутрь представлений:
— @php вставки. Вы пытаетесь реализовать какую-то сложную логику внутри представления, скорее всего этот код вообще протёк и сервиса (о них позже), через контроллер. Двойная протечка.
— вычисления или сложные условия внутри blade-конструкций. Скорее всего код протёк из контроллера, в котором вы недоготовили данные. Также код мог протечь из helper-функций, типа форматирования даты или времени.

Следующий уровень — контроллер.
Симптомы протечки кода внутрь контроллера.
— Запросы к базе данных (прямые или через ОРМ), прямые вызовы стороннего АПИ, запись/чтение файлов. Контроллер не должен знать откуда и как в системе появляются данные, это знают сервисы. Котроллер просит сервисы получитьСписокАктивныхПользователей(), сохранитьКомментарий(), добавитьЛайкКПубликации(). Как и откуда получаются эти данные, контроллер не знает.
— HTML или JSON формируется в контроллере. Это явно куски представления.

Далее сервисы.
Про сервисы я поясню, так как в ванильном Ларавеле их нет. В сервисах мы изолируем техническую часть получения/кеширования и обработки данных. Сервис знает про внешние АПИ, про модели и прочие внутренности системы. Тем не менее сервис не делает прямых запросов к данным, только через ОРМ или обёртки вокруг АПИ. Обычно сервис построен вокруг одной сущности или модели, а смешиваются они уже либо в контроллере, либо в метасервисе (об этом как-нибудь тоже напишу)

Симптомы протечки кода внутрь сервиса.
— Форматирование данных, генерация HTML или JSON. Это должно быть в представлении, через контроллер.
— Прямые запросы к БД или внешним АПИшкам. Только через обёртки.

И под всем этим лежат модели. С ними всё просто. Описывают данные и связи между ними абстрактно от системы хранения. Любая логика в моделях — это протечка кода из вышестоящих блоках.