«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2019/02/24 16:22:41  №1354219 1
Laravel
1. Не понимаю в чем профит сервис контейнера? Уже пересмотрел много видео и статей и примеры. Но я не понимаю через сервис провайдеры мы как бе можем подменять реализации интерфейсов того что будет храниться в сервис контейнере, но мы как бы можем сделать это и без него в чем профит использовать именно его? Да реализация через него синглтона довольна удобно и ясна, но она не так часто нужна, так для чего еще?. Так что вопрос зачем?
2. Заодно вопрос какая структура папок должна быть для контрактов и их реализации.
3. Если бороться с жирными контроллерами через сервисный слой то какую выбрать структуру папок чтоб можно было вернуться к проекту через месяц?
Ответы: >>1354494
Аноним 2019/02/24 21:09:34  №1354494 2
>>1354219

Смысл сервис-контейнера в том, что он может создавать сервисы с зависимостями, не заставляя нас делать это вручную. Принцип DI (внедрение зависимостей) обычно требует передавать зависимости в сервис снаружи. Вручную это выглядит так. Допустим, нам нужен сервис C, который зависит от A и B:

$a = new A;
$b = new B;
$c = new C($a, $b);

С контейнером:

$c = $container->get('C'); // Или $app->make('C') в Laravel

Если что, DI и контейнеры я попытался, как мог, описать в своем уроке: https://github.com/codedokode/pasta/blob/master/arch/di.md - без теории по DI трудно понять, зачем нужен контейнер.

Второй плюс DI контейнера в том, что он умеет сохранять ранее созданный объект и возвращать его, а не создавать новый, при повторном вызове. Это в Ларавель называют "синглтоном".

Далее, ты упомянул "сервис-провайдеры". Это немного другая штука. Они используются, чтобы пачкой зарегистрировать несколько сервисов. Ты мог бы обойтись и без провайдера, и просто зарегистрировать сервисы в контейнере руками, но если ты, например, делаешь библиотеку, то логично объединить предоставляемые ей сервисы в провайдер, чтобы можно было зарегистрировать их одним действием.

> Заодно вопрос какая структура папок должна быть для контрактов и их реализации.

Не знаю, в документации Ларавел не описано?

> Если бороться с жирными контроллерами через сервисный слой то какую выбрать структуру папок чтоб можно было вернуться к проекту через месяц?

А ты разобрался, что такое сервисы? Проблема "толстых контроллеров" в том, что код в них нельзя повторно использовать. Ты описал, например, код регистрации пользователя в контроллере и после этого ты не можешь создать пользователя программно из другого места кода. Сервисы решают эту проблему.

Если у тебя маленький проект, то ты просто кладешь сервисы в одну папку. В простейшем случае можно для каждой сущности сделать свой сервис (сервис для работы с постами, с комментариями, с пользователями). Если большой - то делаешь, например, подпапки, а сами сервисы разделяешь по задачам: сервисы приема платежей, сервисы для подсчета статистики, итд.
Ответы: >>1354575 >>1356055
Аноним 2019/02/25 03:51:48  №1354575 3
>>1354494
резюмируя - в сервис контейнер я пихаю только если у меня присутствует необходимость в зависимости? если у меня просто вспомогательный класс (сервисного слоя) без зависимостей для контроллера я его просто делаю use и использую.
>Не знаю, в документации Ларавел не описано?
контракты в /app/Contracts а реализации их неизвестено где
Ответы: >>1359947
Аноним 2019/03/06 02:32:48  №1359947 4
>>1355798

> что без шаблонизатора мы не можем создать полноценную MVC на пхп

В теории - можем. Например, если мы делаем сервер API, который отдает не HTML-страницы, а данные в формате JSON, то шаблоны нам не нужны. Ну и в теории, опять же, мы можем без шаблонов сделать вывод HTML кода кучей операторов echo.

То есть, шаблон - это лишь один из вариантов реализации View.

Я думаю, ты хотел спросить, "можно ли вместо стороннего шаблонизатора использовать встроенный в PHP?" - да, можно, но неудобно на больших проектах.

Урок про шаблонизаторы: https://github.com/codedokode/pasta/blob/master/php/templates.md

>>1354575

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

Также, контейнер может поддерживать существование одного экземпляра сервиса.

> если у меня просто вспомогательный класс (сервисного слоя) без зависимостей для контроллера я его просто делаю use и использую.

Для вспомогательных классов можно использовать паттерн Utility Class (класс со статичесикими методами).

> контракты в /app/Contracts а реализации их неизвестено где

Их реализации там, где уместно. Естественно, не в папке Contracts. Вообще, ты можешь посмотреть, как код организован в самом Laravel или стандартных библиотеках к нему.

Если у тебя мало сервисов, можно просто сделать папку App/Services. Если много - то думать, как дробить на части. Можно как-то по смыслу их группировать, по разделу сайта, по компоненту приложения.

>>1354604

По идее так: http://php.net/manual/ru/language.basic-syntax.phpmode.php

Но это даст низкокачественный код, потому читай https://github.com/codedokode/pasta/blob/master/php/templates.md