slimphp

Е, тъй като предишният ми пост в Slim изглежда е добре приет, тук е по-напреднал пост. В този пост ще опиша как използвам Slim на работното място и това, което открих, работи наистина добре.

Pimple е страхотен контейнер, но открих, че липсата на автоматично окабеляване е малко мъчително, затова предпочитам да използвам PHP-DI чрез (http://php-di.org/doc/frameworks/slim.html ). Използвам PHP-DI с персонализиран клас на приложение, който изглежда така:

Файлът di-container.php е наистина прост и съдържа PHP масив, който съдържа всички "root" зависимости за даден проект. Обикновено това е ограничено до: Doctrine, Twig, Mailgun, Command Bus, Event Dipatcher, Redis. и т.н. Наличието на всички „root“ зависимости ми спестява да се налага да пиша целия свързващ код за моя домейн (който може да бъде огромен. Текущият проект има 250+ класа на домейна). Ако имате различни конфигурации, от които се нуждаете, можете да добавите инфраструктура във вашия клас APP, за да заредите различни di-config в зависимост от вашата среда.

Това си струва; производителност. така че само имайте предвид, че не е безплатно средно към заявката ви може да се добавят 5ms.

Минимален PHP-DI di-container.php:

В Slim поддържаме стила на анонимната функция за действия по маршрута, но предлагам никой да не ги използва в производството. Вместо това винаги съм препоръчвал на хората да използват класове за действие. Пол Джоунс написа хубава статия за това как да използвате класове за действие в Slim 3 Action-Domain-Responder.

След като казах, че когато хората започват да използват Slim и разбират как работи PSR-4, препоръчвам на всички да използват името на класа за разрешаване на услуги в контейнера. Това е доста необходимо при използване на PHP-DI, но всъщност никъде не е написано. Константата на класа е много мощна, особено когато става въпрос за поддържане на приложения, сякаш премествате или рефакторирате имена на класове, тогава PHPStorm е в състояние да направи всичко за вас и не губите време за промяна на низове!

Не забравяйте, че класовете Action трябва да изпълняват публична функция __invoke (Request $ request, Response $ response) и ако използвате PHP-DI, тогава подписът се променя, за да включва параметъра userId! публична функция __invoke ($ userId, Request $ request, Response $ response) Намирам това за много удобно!

Груповите маршрути са удобна функция, която в крайна сметка е конструктор на URI. Това е много лесен начин за картографиране на междинния софтуер с цели блокове маршрути и спестява необходимостта да пишете -> добавяне (Middleware) навсякъде.

Мисля, че в крайна сметка този стил е по-четим и е по-лесен за проследяване, когато файлът ви с маршрути има много дефиниции на маршрути.

Аз лично използвам следната структура, но няма абсолютно никаква необходима структура за вашето приложение:

  • конфиг /
  • шаблони /
  • src /
  • тестове /
  • intl /
  • цилиндър /
  • обществено /
  • трупи /

Открих, че е по-лесно, ако предадете действителен тънък обект, а не подиграван. Следният код е чудесно място за започване!

Ако имате въпроси, не се колебайте да се свържете с мен! Мога да бъда намерен на тази платформа, Twitter или на SlimPHP (Slack Channel/IRC Channel)