Comments 14
Думаю, многим будет полезно.
К сожалению, пропущено описание interface injection, интересная возможность о которой мало документации.
Причем тут SOA, если честно, не понял.
ЗЫ ну и с подсветкой кода какие-то проблемы.
К сожалению, пропущено описание interface injection, интересная возможность о которой мало документации.
Причем тут SOA, если честно, не понял.
ЗЫ ну и с подсветкой кода какие-то проблемы.
Соглашусь, что SOA тут не причем и автор наверное не знает сути этого понятия. Под Service в SOA в частном случае очень часто понимают какой-либо веб-сервис, общение с которым происходит при помощи известных протоколов вроде SOAP.
Согласен, понимаю, что SOA к DI отношения не имеет, но я хотел связать между собой эти понятия в архитектуре Symfony2, видимо, не получилось.
Ну тема тоже дельная, но если хотите об этом рассказать, то лучше — отдельным топиком. IoC — сама по себе более чем самодостаточная тема.
Тут вопрос далеко не простой. Правильно спроектированные симфонийские сервисы могут отвечать всем принципам SOA, кроме платформы. И всегда остается возможность обернуть вызов стороннего сервиса в симфонийский сервис, как и предоставить гейт для вызова симфонийского сервиса извне. В то же время в контейнер можно включить сервис, который принципам SOA вообще не соответствует.
Прочитал спецом, всегда было интересно — а как вообще в PHP используют IoC, и, в особенности, DI.
И не увидел, собственно, DI. Прямое обращение к контейнеру «за нужным объектом» — это паттерн Service Locator, а не Dependency Injection. Точнее, вы конечно «внедряете» контейнер через конструктор — но это не показательно. Обычно через конструктор внедряется что-нибудь другое, конкретный сервис, и это и будет DI (чтобы вся цепочка объектов ничего не знала о контейнере — собственно, главный минус Service Locator'а как раз в том, что получается зависимость от Locator'а).
P.S. И да, как уже сказали выше, SOA тут ни при чем. Это совсем другая тема.
И не увидел, собственно, DI. Прямое обращение к контейнеру «за нужным объектом» — это паттерн Service Locator, а не Dependency Injection. Точнее, вы конечно «внедряете» контейнер через конструктор — но это не показательно. Обычно через конструктор внедряется что-нибудь другое, конкретный сервис, и это и будет DI (чтобы вся цепочка объектов ничего не знала о контейнере — собственно, главный минус Service Locator'а как раз в том, что получается зависимость от Locator'а).
P.S. И да, как уже сказали выше, SOA тут ни при чем. Это совсем другая тема.
Сервис 'some_service_name' в качестве аргумента конструктора принимает другой сервис, назовем его к примеру 'reference_service'. Контейнер знает про все эти зависимости, и в случае обращения к первому сервису создает сам экземпляр второго и подставляет в первый.
В конечном итоге да, получение сервиса внутри action-контроллера выглядит именно как обращение к Service Locator'у.
Что-то как-то over-engineered. Древний phemto куда элегантнее.
Чем это отличается (не реализация, а именно смысл) от паттерна «реестр»? Ну кроме того, что здесь я так понимаю, мы можем описать интерфейс самого сервиса, но зачем его таким способом описывать, чем стандартные интерфейсы хуже?
Sign up to leave a comment.
Symfony2 Dependency Injection в разрезе