Быстродействие зависит от самого IoCC. Castle Windsor, например, узнает требуемые зависимости через рефлексию. В Autofac же, их нужно прописывать явно. Конечно, в этом случае Autofac будет быстрее, но все равно это не bottleneck в приложении. :)
Попробую внести ясность, мне вообще не понравилось, что автор этой статьи склоняет к использованию Service Locator'a.
Service Locator — это не DI в смысле Dependency Injection, а это DI в смысле Dependency Inversion.
Dependency Injection — Это подача зависимости классу извне. Простыми словами звучит так: не инстанциируй сущности, не предназначенные для инстанцииорвания сущностей, внутри других сущностей, но если нужно инстанциирование сущностей — используй для этого специализированные сущности (фабрики, например).
Сервис-локатор же получает некий сервис «изнутри» класса. Он как бы говорит, что «мне нужно это, дайте немедленно». Хорошим подходом же является декларативное объявление требований зависимостей. Не используя никакие сервис локаторы, просто объявляем в конструкторе, что нам нужно. Для решения таких зависимостей нам поможет Inversion of Control Contrainer. Ninject, кстати, им является.
Dependency Inversion — это связывание модулей нижнего уровня на высоком уровне. Одним из вариантов которого является связывание реализаций при помощи интерфейсов. Поэтому Service Locator можно к этому отнести.
Service Locator является Dependency Inversion, Dependency Injection является Dependency Inversion, но Service Locator это не Dependency Injection.
Когда вы используете Service Locator внутри сущности, вы отвязываетесь от других зависимостей по интерфейсу. Но при этом привязываетесь реализацией к сервис-локатору. Это не является декаплингом (decoupling) зависимостей, и прежде всего поэтому это антипаттерн. Подробнее можно почитать на википедии, например. Английской, конечно же.
Наиболее удобным путем внедрения зависимостей является использование Inversion of Control контейнера, коим и является Ninject. Когда вы используете IoCC, вы не используете в своих классах некие сомнительные сторонние сервисы, синглторы, депенденси резолверы и сервис-локаторы. IoCC позволяют настраивать время жизни объектов. Они сами решают, что нужно запрашиваемым сущностям, и делают это в рантайме.
ASP.NET MVC позволяет перегружать фабрику контроллеров своей, поэтому осуществить депенденси резолвинг контроллеров можно там. И все, это первое и последнее место, где вы использовали IoCC напрямую. Во всех других местах всё начнет работать автоматически.
DI через проперти семантически отличается от DI через конструктор тем, что инъекция вобщем-то может и не произойти, или, например, объект может быть изменен после создания. К тому же, вне IoCC окружения, этот модуль необходимо будет создавать особым образом, помня, какие проперти обязательны к установке, а какие нет. Это частный случай Sequential coupling, что является антипаттерном.
Вы как бы пытаетесь развязать зависимости модулей друг от друга, но в то же время жестко подвязываетесь на сам Service Locator. Теряется реюзабельность. Выходит, что модули без определенного и конкретного Service Locator'a существовать не могут, придется воссоздавать окружение. И именно поэтому использование Service Locator'a тоже является антипаттерном. Но, конечно, есть случаи, где по-другому никак, но не в этих примерах в статье.
По этим причинам предпочтительнее делать инъекцию обязательных зависимостей через конструктор в readonly поля. Либо, в случае инъекций в проперти, обеспечить иммутабельность object reference для зависимости и потокобезопасное выполнение. Но это же ненужные сложности. :)
Не всем нужны, но почти никто бы не отказался от к примеру NOKIA N8. Все упирается в цену. Чтобы вы выбрали если бы iphone или N8 или LG Optimus стоили на одной планке с телефоном, предложенного вами уровня? Люди склонны к роскоши, есть конечно такие как Диаген, но их единицы.
> Александер напомнил о двух кибер-атаках на целые государства – на Эстонию (в 2007 г., после демонтажа «Бронзового солдата») и на Грузию (в 2008 г., во время войны с Россией).
И снова не обошлось без подозрений, направленных на Россию. Ведь РФ выступает за мирное разрешение ядерного вопроса относительно Ирана. (С Израилем тут все понятно, на «него первого подумали») Но что если США, штаты как раз за радикальные меры. Хотя не очень понятно за чем им такое, выставлять жертвой Иран не выгодно, может как средство сдерживания на коротком поводке и противовес иранской ядерной программе? Сугубо мое личное мнение.
Достаточно объемная статья, имел везение находится на лекции компании DataArt, посвященной именно стартапам. Признаюсь у вас очень хорошее начало, излагаете в приятной форме, было интересно читать, жду новых статей… :)
А тем временем комиссия по делам демографии Китая решила использовать это в своих целях, купи 10 презервативов с яблочным вкусом общей стоимостью в $1042 и получи iPad — бесплатно!
А ведь кагда-то это звучало бы смешно, а сейчас реальность! Да еще какая! Люди, работающие в google, реально думают о будущем, о безопасности людей. Вот чем гугл завоевывает популярность и любовь потребителей! Конечно они не забывают и о коммерческой прибыли, как же без нее, это бизнес, НО это ведь рискованный шаг, всякое новое, незнакомое — уже риск! А google все равно делает, делает, будет продолжать делать, и слава богу — пока большинство проектов удачно!
Что если еще приплести сюда конфликт между Apple и Adobe. В ходе конфликта небезызвестный Стив критиковал Flash. Flash — закрытая технология, flash — не оптимизирован под мобильные устройства. На Adobe в связи с этим навалили огромное количество критики. Ходят слухи, что adobe будет вытеснятся с рынка (Silverlight), либо полностью противоположный вариант, что кстати более вероятно. Microsoft хочет усилить свои позиция объединившись против Apple, а там и google с android на пятки наступает
Service Locator — это не DI в смысле Dependency Injection, а это DI в смысле Dependency Inversion.
Dependency Injection — Это подача зависимости классу извне. Простыми словами звучит так: не инстанциируй сущности, не предназначенные для инстанцииорвания сущностей, внутри других сущностей, но если нужно инстанциирование сущностей — используй для этого специализированные сущности (фабрики, например).
Сервис-локатор же получает некий сервис «изнутри» класса. Он как бы говорит, что «мне нужно это, дайте немедленно». Хорошим подходом же является декларативное объявление требований зависимостей. Не используя никакие сервис локаторы, просто объявляем в конструкторе, что нам нужно. Для решения таких зависимостей нам поможет Inversion of Control Contrainer. Ninject, кстати, им является.
Dependency Inversion — это связывание модулей нижнего уровня на высоком уровне. Одним из вариантов которого является связывание реализаций при помощи интерфейсов. Поэтому Service Locator можно к этому отнести.
Service Locator является Dependency Inversion, Dependency Injection является Dependency Inversion, но Service Locator это не Dependency Injection.
Когда вы используете Service Locator внутри сущности, вы отвязываетесь от других зависимостей по интерфейсу. Но при этом привязываетесь реализацией к сервис-локатору. Это не является декаплингом (decoupling) зависимостей, и прежде всего поэтому это антипаттерн. Подробнее можно почитать на википедии, например. Английской, конечно же.
Наиболее удобным путем внедрения зависимостей является использование Inversion of Control контейнера, коим и является Ninject. Когда вы используете IoCC, вы не используете в своих классах некие сомнительные сторонние сервисы, синглторы, депенденси резолверы и сервис-локаторы. IoCC позволяют настраивать время жизни объектов. Они сами решают, что нужно запрашиваемым сущностям, и делают это в рантайме.
ASP.NET MVC позволяет перегружать фабрику контроллеров своей, поэтому осуществить депенденси резолвинг контроллеров можно там. И все, это первое и последнее место, где вы использовали IoCC напрямую. Во всех других местах всё начнет работать автоматически.
Мне из всех IoCC контейнеров под .NET больше всего нравится Castle Windsor. Он очень чистый, не мешается с вашим кодом и постоянно развивается. Можете почитать пример внедрения Castle Windsor в ваше ASP.NET MVC приложение.
Вы как бы пытаетесь развязать зависимости модулей друг от друга, но в то же время жестко подвязываетесь на сам Service Locator. Теряется реюзабельность. Выходит, что модули без определенного и конкретного Service Locator'a существовать не могут, придется воссоздавать окружение. И именно поэтому использование Service Locator'a тоже является антипаттерном. Но, конечно, есть случаи, где по-другому никак, но не в этих примерах в статье.
По этим причинам предпочтительнее делать инъекцию обязательных зависимостей через конструктор в readonly поля. Либо, в случае инъекций в проперти, обеспечить иммутабельность object reference для зависимости и потокобезопасное выполнение. Но это же ненужные сложности. :)
И снова не обошлось без подозрений, направленных на Россию. Ведь РФ выступает за мирное разрешение ядерного вопроса относительно Ирана. (С Израилем тут все понятно, на «него первого подумали») Но что если США, штаты как раз за радикальные меры. Хотя не очень понятно за чем им такое, выставлять жертвой Иран не выгодно, может как средство сдерживания на коротком поводке и противовес иранской ядерной программе? Сугубо мое личное мнение.
P.S. Stuxnet аля Skynet (Terminator) :D
А ведь кагда-то это звучало бы смешно, а сейчас реальность! Да еще какая! Люди, работающие в google, реально думают о будущем, о безопасности людей. Вот чем гугл завоевывает популярность и любовь потребителей! Конечно они не забывают и о коммерческой прибыли, как же без нее, это бизнес, НО это ведь рискованный шаг, всякое новое, незнакомое — уже риск! А google все равно делает, делает, будет продолжать делать, и слава богу — пока большинство проектов удачно!