Публикации - Решение проблемы "толстых" контроллеров и моделей архитектурного шаблона проектирования HMVC в фрэймворке Laravel

Усовершенствование HMVC в фрэймворке Laravel

Усовершенствование концепции HMVC в фрэймворке Laravel заключается во введении вспомгательных и промежуточных решений применяемых во взаимодействии контроллеров с моделями. Такими решениями являются:

  • middleware, или подготовительное программное обеспечение,
  • serviceProvider, или классы библиотек,
  • другие решения.

Middleware

HTTP Middleware (подготовительное программное обеспечение) - это фильтры обработки HTTP-запроса. Так, например, в Laravel включены middlewares для проверки аутентификации пользователя. Если пользователь не авторизирован, middleware перенаправляет его на страницу логина. Если же авторизирован - middleware не вмешивается в прохождение запроса, передавая его дальше по цепочке middleware-посредников к собственно приложению.

Middlewares можно использовать в качестве фильтров для роутов.

Конечно, проверка авторизации - не единственная задача, которую способны выполнять middlewares. Это также добавление особых заголовков (например, CORShttp-ответ вашего приложения) или логирование всех http-запросов.

В Laravel есть несколько дефолтных middleware, которые находятся в папке app/Http/Middleware. Это middlewares для реализации режима обслуживания сайта ("сайт временно не работает, зайдите позже"), проверки авторизации, CSRF-защиты и т.п.

Создание middleware

Для создания middleware можно воспользоваться встроенной artisan-командой make:middleware:

 

php artisan make:middleware NameMiddleware

 

ServiceProvider

Основная задача поставщика услуг, или ServiceProviders – это загрузка вспомогательных, в том числе, и собственных классов.

Если открыть конфигурационный файлa app.php, то мы увидим там множество провайдеров, определенных в массиве providers. Это все классы, которые будут загружены для приложения. Многие из них являются отложенными, что означает, что они не будут загружаться при каждом запросе, а только тогда, когда они действительно необходимы, т.е. когда они будут вызываться.

Все провайдеры должны наследоваться от класса Illuminate\Support\ServiceProvider. Данный абстрактный класс требует, чтобы был определен хотя бы один метод класса-провайдера: register. В этом методе регистрируется вспомогательный класс.

Сам провайдер можно создать с помощью artisan:

 

php artisan make:provider NameServiceProvider

 

Так выглядит пустой класс ServiceProvider

 

class SizeServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap the application services.
     *
     * @return void
     */
    public function boot()
    {
    }

    /**
     * Register the application services.
     *
     * @return void
     */
    public function register()
    {
         
    }
}

 

Пространство имени App\Providers, в котором находится этот класс сервис-провайдера, - место для хранения сервис-провайдеров нашего Laravel-приложения, но мы можете располагать свои сервис-провайдеры где угодно внутри PSR-4 папки (если вы не меняли composer.json, то это папка app).

После вызова методов register() всех сервис-провайдеров приложения, вызывается метод boot(). Там уже можно использовать весь существующий функционал классов фреймворка и приложения - регистрировать слушателей событий, подключать роуты и т.п.

Метод register() предназначен для загрузки вспомогательных классов с предопределенными входящими параметрами, которые определяются в этом же методе. Для всего остального предназначен метод boot().

Другие решения

Использование в разработке middleware и serviceProvider-ов помогают облечить контроллеры. Однако это не все усовершенствования, привнесенные в HMVC фрэймворком Laravel. Стоит еще отметить классы Request и прослушиватели моделей. Но это уже темы отдельных публикаций.

Количество комментариев: 0

Для того, чтобы оставить коментарий необходимо зарегистрироваться