Comments 18
Конечно, к сервис ориентированной архитектуре (SOA) это имеет достаточно отдаленное отношение.
В чем преимущество перед указанными «соперниками»? В чем тяжесть симфоневской реализации? Почти уверен что при при дампинге в класс sf di выиграет достаточно много.
Прототипы через клонирование не лучший вариант. Как отдельная фишка — мб, но в основе должен быть вариант простого пересоздание сервиса.
В общем, пока не понятно «зачем».
В чем преимущество перед указанными «соперниками»? В чем тяжесть симфоневской реализации? Почти уверен что при при дампинге в класс sf di выиграет достаточно много.
Прототипы через клонирование не лучший вариант. Как отдельная фишка — мб, но в основе должен быть вариант простого пересоздание сервиса.
В общем, пока не понятно «зачем».
Мне в моём проекте нужен был DI, я взял естественно то с чем уже знаком из Symfony, но он мне не подходил, после работал с Pimple, но в нём не хватало функциональности. Я решил создать что-то среднее между ними. Вот «зачем» :)
PS Конечно же я мог оставить эту библиотеку только для себя, однако могут оказаться люди для которых пригодиться моя реализация.
PS Конечно же я мог оставить эту библиотеку только для себя, однако могут оказаться люди для которых пригодиться моя реализация.
Долго смотрел на картинку и не мог понять, что же в ней не так :)
не понимаю в чем преимущество поддерживать такую конфигурацию, вместо того, чтобы все эти сервисы прописать вручную.
Плюсы реализации: никакой магии, всегда знаем что в контейнере, никаких плясок с бубном вокруг конфигурации (почему оно незаинжектилось), можно явно удалять-добавлять сервисы.
Минусы: чуть сложнее реализовать LazyLoading и… Дописывайте в комментариях )
class DIC {
function getService1()
{
return new Service1();
}
function getService2()
{
return Serivce2($this->getService1());
}
}
Плюсы реализации: никакой магии, всегда знаем что в контейнере, никаких плясок с бубном вокруг конфигурации (почему оно незаинжектилось), можно явно удалять-добавлять сервисы.
Минусы: чуть сложнее реализовать LazyLoading и… Дописывайте в комментариях )
Начинают все с простой реализации, затем добавляют LazyLoading и… через несколько интераций приходят к своему DI. :)
Потому что у вас не DI-контейнер, а Service Locator. И это антипаттерн.
Пусть у меня где-то в каком-то классе идёт следующий код:
Кроме как заменить new DIC() на свой класс унаследованный от DIC не получиться.
$dic = new DIC();
$service1 = $dir->getService1();
Кроме как заменить new DIC() на свой класс унаследованный от DIC не получиться.
Не-не-не, не надо такого кода, это тот же самый Service Locator. Это ничем не отличается от просто фабрики или даже вызовы конструктора и здесь нет инверсии зависимости.
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
А по поводу кода Davert`a — хороший DI-контейнер еще позволяет управлять жизненным циклом создаваемых объектов и задавать все зависимости в одном месте.
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
А по поводу кода Davert`a — хороший DI-контейнер еще позволяет управлять жизненным циклом создаваемых объектов и задавать все зависимости в одном месте.
Не совсем понял в чем проблема и что должно было получиться.
Исходя из логики в статье
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
DIC ничем не лучше.
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.
DIC ничем не лучше.
C DIC у вас зависимости прописаны в конструкторах. В языках со статической типизацией падать будет в compile time.
Стоп, а сервисы всё равно вытаскиваются из контейнера через get.
И вот в этот момент get'а будет происходить магия и падение.
И вот в этот момент get'а будет происходить магия и падение.
Нет. get типизован под конкретный тип. Как именно типизован — зависит от конкретного языка. Но тип есть и его проверка произойдет при компиляции.
(я еще раз зачему, что это верно для языков со статической типизацией).
(я еще раз зачему, что это верно для языков со статической типизацией).
В Symfony2 get типизирован под… вообщем никак он не типизирован. То же и в Pimple.
В чем собственно и печалька.
Потому я считаю, что так строить контейнеры нельзя.
Из всех вариантов я вижу 2:
— статически строить контейнер и дампить в файл. Но чтобы метода доступа к сервисам всегда были публичными.
— строить контейнер ручками.
В чем собственно и печалька.
Потому я считаю, что так строить контейнеры нельзя.
Из всех вариантов я вижу 2:
— статически строить контейнер и дампить в файл. Но чтобы метода доступа к сервисам всегда были публичными.
— строить контейнер ручками.
Sign up to leave a comment.
Внедрение зависимости c Inversion