http://habrahabr.ru/rss/post/62830/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 12:28:49 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif http://habrahabr.ru/blogs/net/62830/#comment_1760496 http://habrahabr.ru/blogs/net/62830/#comment_1760496
самое простое решение — архитектура черных ящиков, или «черных слоев», когда при пуске приложения контейнер проходит по всем слоям и регистрирует задаваемые слоями реализации. При этом в сборке реализацию можно скрыть от лишних глаз, т.е. добиться полной инкапсуляции в слое. А это очень круто.

>Чем IoC лучше?
Да ничем он не лучше. Это просто паттерн автоматического определения зависимостей. Он есть в контейнере Unity. Контейнер Юнити описывается автором только потому, что это типа «модное и современное» решение, хотя, судя по ответам на технические вопросы, автор только-только что-то прочитал. IoC можно вообще убрать, написав свой контейнер или взяв простой существующий. System.ComponentModel.Design.ServiceContainer, например (хотя, если вы джавист, то это вам ничего не скажет).

Фишка удобства тестирования не выходит из концепции Unity, а выходит из концепции построения классов, которые удовлетворяют шаблону определения зависимостей. Ты должен или проставить зависимость в конструкторе или в свойстве класса, причем, желательно определив интерфейс. Значит, очень легко настроить mock зависимостей (мок интерфейса очень легко сделать) и протестировать фукнционал класса. Unity контейнер здесь не причем. Он всего лишь вставляет зависимости.

]]> Thu, 02 Jul 2009 14:27:12 GMT acerv http://habrahabr.ru/blogs/net/62830/#comment_1746360 http://habrahabr.ru/blogs/net/62830/#comment_1746360 Sat, 27 Jun 2009 16:13:23 GMT keith http://habrahabr.ru/blogs/net/62830/#comment_1745210 http://habrahabr.ru/blogs/net/62830/#comment_1745210 Fri, 26 Jun 2009 21:22:35 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1744499 http://habrahabr.ru/blogs/net/62830/#comment_1744499 Fri, 26 Jun 2009 15:18:41 GMT LunarFrog http://habrahabr.ru/blogs/net/62830/#comment_1744369 http://habrahabr.ru/blogs/net/62830/#comment_1744369 Fri, 26 Jun 2009 14:29:32 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1744365 http://habrahabr.ru/blogs/net/62830/#comment_1744365 Fri, 26 Jun 2009 14:26:29 GMT LunarFrog http://habrahabr.ru/blogs/net/62830/#comment_1744358 http://habrahabr.ru/blogs/net/62830/#comment_1744358 Fri, 26 Jun 2009 14:21:53 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1744349 http://habrahabr.ru/blogs/net/62830/#comment_1744349 Fri, 26 Jun 2009 14:20:22 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1741736 http://habrahabr.ru/blogs/net/62830/#comment_1741736
BeanFactory factory = new XmlBeanFactory(«beans.xml»);
]]> Thu, 25 Jun 2009 16:24:38 GMT xibyte http://habrahabr.ru/blogs/net/62830/#comment_1741540 http://habrahabr.ru/blogs/net/62830/#comment_1741540
Давайте я дам конкретный пример.
У меня есть модуль–блог. Данные храню на своем сервере. Пришел заказчик, сказал, что у него уже есть блог на Google Blogger'e. Поскольку у меня был легкий сервис, отделенный от всей логики, который только и делал, что писал и читал в/из базы, я заменил его другим, который стал писать и читать в/из сервисов Google Blogger.

Применив Unity, я заменил только тонкий сервис, не трогав ничего остального и не переписывая тесты главной логики.

Если завтра придет другой чувак и попросит использовать другой движок – сделать это будет легко, и самое главное – у меня не будет болеть голова, что я что–то сломаю. Тесты проходят на главную логику, отдельные на сервис – значит все в порядке.]]> Thu, 25 Jun 2009 14:43:54 GMT micbsv http://habrahabr.ru/blogs/net/62830/#comment_1741293 http://habrahabr.ru/blogs/net/62830/#comment_1741293 Если абстрагироваться от всяческих фреймворков и .NET… Правильно же, что IoC это такой хитрый контейнер, который может отдать объект по классу. А если он ещё и отслеживает зависимости и удовлетворяет их, то тут ещё и DI.
Так вот вопрос: если всё это так, то чем IoC-контейнер отличается от фабрики?]]> Thu, 25 Jun 2009 13:05:50 GMT alexzzam http://habrahabr.ru/blogs/net/62830/#comment_1740292 http://habrahabr.ru/blogs/net/62830/#comment_1740292 gandjustas.blogspot.com . Там есть толковые посты по теме, найти их можно по тегам «UNITY», «IOC-КОНТЕЙНЕР».]]> Thu, 25 Jun 2009 08:34:52 GMT Qbit http://habrahabr.ru/blogs/net/62830/#comment_1740027 http://habrahabr.ru/blogs/net/62830/#comment_1740027 позволяет переконфигурировать приложение без перекомпиляции. Модули (jar'ки) добавляются, удалятся, заменяются, переопределяя друг друга — в итоге получаем нужную конфигурацию для конкретного деплоймента.]]> Thu, 25 Jun 2009 07:09:13 GMT porchini http://habrahabr.ru/blogs/net/62830/#comment_1739843 http://habrahabr.ru/blogs/net/62830/#comment_1739843
Одна из идей IOC в том, чтобы собрать независимые модули системы вместе. А идея юнит тестирования чтобы эти независимые модули протестировать. Так что IOC и юнит тестирование тесно связаны и всегда используются вместе. ]]> Thu, 25 Jun 2009 05:39:44 GMT xibyte http://habrahabr.ru/blogs/net/62830/#comment_1739806 http://habrahabr.ru/blogs/net/62830/#comment_1739806 Thu, 25 Jun 2009 05:24:23 GMT ostapbender http://habrahabr.ru/blogs/net/62830/#comment_1739688 http://habrahabr.ru/blogs/net/62830/#comment_1739688 Thu, 25 Jun 2009 02:41:25 GMT paradoxs http://habrahabr.ru/blogs/net/62830/#comment_1739660 http://habrahabr.ru/blogs/net/62830/#comment_1739660 habrahabr.ru/blogs/net/62830/#comment_1739659]]> Thu, 25 Jun 2009 01:36:18 GMT beq http://habrahabr.ru/blogs/net/62830/#comment_1739659 http://habrahabr.ru/blogs/net/62830/#comment_1739659 Thu, 25 Jun 2009 01:35:58 GMT beq http://habrahabr.ru/blogs/net/62830/#comment_1739637 http://habrahabr.ru/blogs/net/62830/#comment_1739637 Thu, 25 Jun 2009 00:32:58 GMT Qbit http://habrahabr.ru/blogs/net/62830/#comment_1739593 http://habrahabr.ru/blogs/net/62830/#comment_1739593 Тогда непонятно в чём бонус.

А разве можно написать хоть немного сложное приложение без использования сторонних фреймворков?]]> Wed, 24 Jun 2009 23:24:54 GMT ashmind http://habrahabr.ru/blogs/net/62830/#comment_1739513 http://habrahabr.ru/blogs/net/62830/#comment_1739513 Wed, 24 Jun 2009 22:05:10 GMT muse http://habrahabr.ru/blogs/net/62830/#comment_1739446 http://habrahabr.ru/blogs/net/62830/#comment_1739446 Wed, 24 Jun 2009 21:23:54 GMT muse http://habrahabr.ru/blogs/net/62830/#comment_1739306 http://habrahabr.ru/blogs/net/62830/#comment_1739306 Wed, 24 Jun 2009 20:17:22 GMT andycaramba http://habrahabr.ru/blogs/net/62830/#comment_1739293 http://habrahabr.ru/blogs/net/62830/#comment_1739293 Wed, 24 Jun 2009 20:07:50 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739257 http://habrahabr.ru/blogs/net/62830/#comment_1739257
Если в бизнес приложении никогда нет необходимости в автоматическом IService[], то это не слишком удачная архитектура.
Фабрики надо писать и поддерживать, хороший контейнер — не надо (XML ни разу не использовал, зачем).

В юнит тестировании очень помогает automocking container, но это не столь важно. Важнее то, что когда классы спроектированны так, чтобы все вспомогательные объекты можно было переопределить через свойства или конструктор, то чтобы создать их в самом приложении можно:
a) либо написать много кода, который ссылается на все библиотеки приложения и требует поддержки
б) использовать IoC

Я обычно выбираю пункт б).]]> Wed, 24 Jun 2009 19:43:24 GMT ashmind http://habrahabr.ru/blogs/net/62830/#comment_1739253 http://habrahabr.ru/blogs/net/62830/#comment_1739253 вкусностей, понравилась его легковесность и простота конфигурации. Всё-таки Unity немного громоздок, посмотрите например на код его материализатора объектов.

P.S. IoC используем для разработки линейки продуктов.]]> Wed, 24 Jun 2009 19:41:07 GMT brainunit http://habrahabr.ru/blogs/net/62830/#comment_1739252 http://habrahabr.ru/blogs/net/62830/#comment_1739252
dimecasts.net/Casts/ByTag/IoC]]> Wed, 24 Jun 2009 19:41:03 GMT LunarFrog http://habrahabr.ru/blogs/net/62830/#comment_1739251 http://habrahabr.ru/blogs/net/62830/#comment_1739251 Wed, 24 Jun 2009 19:40:54 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739248 http://habrahabr.ru/blogs/net/62830/#comment_1739248 Wed, 24 Jun 2009 19:39:57 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739246 http://habrahabr.ru/blogs/net/62830/#comment_1739246 InjectorProperty. Или добавлять marker interface для обоих сервисов. Или декларировать их как конкретные типы. Или задать им имена и резолвить вручную, по имени. (но это уже не DI)]]> Wed, 24 Jun 2009 19:39:24 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739239 http://habrahabr.ru/blogs/net/62830/#comment_1739239 По логике, если они имплементируют один и тот же интерфейс, то и использование у них будет однородное.

В таком случае параметр можно заменить на IService[] services и дальше работать со всеми имплементациями сразу.]]> Wed, 24 Jun 2009 19:36:01 GMT ashmind http://habrahabr.ru/blogs/net/62830/#comment_1739234 http://habrahabr.ru/blogs/net/62830/#comment_1739234 Wed, 24 Jun 2009 19:33:48 GMT ashmind http://habrahabr.ru/blogs/net/62830/#comment_1739202 http://habrahabr.ru/blogs/net/62830/#comment_1739202 Wed, 24 Jun 2009 19:16:46 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739199 http://habrahabr.ru/blogs/net/62830/#comment_1739199 James Kovacs' roll-your-own IoC container. Более доходчивого описания IoC не всречал.]]> Wed, 24 Jun 2009 19:15:24 GMT gimalay http://habrahabr.ru/blogs/net/62830/#comment_1739166 http://habrahabr.ru/blogs/net/62830/#comment_1739166 public class MyFirstServiceImpl : IService{}
public class MySecondServiceImpl : IService{}
]]> Wed, 24 Jun 2009 19:02:33 GMT just_vladimir http://habrahabr.ru/blogs/net/62830/#comment_1739162 http://habrahabr.ru/blogs/net/62830/#comment_1739162
— обеспечить связывание инфраструктуры контроллеров MVC с инъектором
— модульность
— уникальность контейнера в разрезе сессии

Я бы расписал все, но блин, не успеваю вообще ничего, кроме работы. А вам в рамках обучающих методик будет полезно, имхо.]]> Wed, 24 Jun 2009 19:00:56 GMT acerv http://habrahabr.ru/blogs/net/62830/#comment_1739136 http://habrahabr.ru/blogs/net/62830/#comment_1739136
DI столь же уместны как и фабрики. В случае с DI код получается «прозрачнее» — обычно нет необходимости явного требования объекта, создание необходимых экземпляров проходит за сценой. К тому же, проще сконфигурировать одно правило, чем добавить фабрику.

Переопределение свойств в ручную — это хорошо, но когда у тебя сотня классов, создавать связи в ручную не очень интересно.

Цель DI — избежать самокофигурирующихся объектов, т.к. это снижает возможность их повторного использования и тестирования.]]> Wed, 24 Jun 2009 18:44:59 GMT LunarFrog http://habrahabr.ru/blogs/net/62830/#comment_1739135 http://habrahabr.ru/blogs/net/62830/#comment_1739135
Примеров актуального использования контейнеров в сети — миллион. Один из примеров — когда при неправильно работающем приложении нужно заменить обычную реализацию на динамический прокси с детальным логгированием. Без перекомпиляции. На живой системе. Тут-то внешняя конфигурация и спасает — меняем XML и все. А вообще примеров много, если долго пользовать, то потом не сможешь без этого жить.

Насчет Unit-тестирования — допустим объект А зависит от В, а от — от С. С создается в В без моего ведома. А теперь вопрос — как я могу подменить тот объект, который создается без моего участия вообще? Правильно, я не могу — если только не начну вообще все цепочки создавать вручную, что просто нереально. С контейнером же, я могу подменить реализацию объекта, независимо от того, на какой он «глубине» находится.

Тут я имел ввиду что если, например, для использования какого-то сервиса его нужно настраивать (к пр. передавать гору данных в конструктор), то легче это действие централизовать чтобы потом можно было эту конфигурацию менять централизованно. В тех же unit-тестах, например.]]> Wed, 24 Jun 2009 18:44:55 GMT mezastel http://habrahabr.ru/blogs/net/62830/#comment_1739084 http://habrahabr.ru/blogs/net/62830/#comment_1739084 Wed, 24 Jun 2009 18:12:15 GMT Ordos http://habrahabr.ru/blogs/net/62830/#comment_1739079 http://habrahabr.ru/blogs/net/62830/#comment_1739079 Другие контейнеры
Несколько лет назад я прочитал ту самую статью Фаулера и загорелся. И стал я использовать Spring Framework. Отличная, надо сказать, библиотечка. Представляет очень функциональность по гибкую xml-настройке DI.
Чем данный IoC контейнер (Unity) лучше хотя бы того же Spring?

Про бой и бизнес приложения
Ни одного реального, а главное уместного примера применения IoC контейнеров в бизнес приложениях пока не встречал, обычно их используют ради технологического фетишизма или из особой любви к Фаулеру.
Все места, где использовался IoC, в моем рабочем проекте были безжалостно заменены на обычные фабрики т.к. стало ясно, что без перекомпилляции никогда нет нужды подменять реализацию, а дополнительная, не нужная в боевых условиях, xml-конфигурация только отягощяет решение.
Вопрос такой, в какой системе IoC контейнер может быть полезен при разработке бизнес приложений и на бою?
Даже так, в каких реальных приложениях его использование может быть уместно?

Про unit тестирование
Если хочешь unit-тестировать код, спроектируй его так, чтобы IoC был не нужен, а все вспомогательные объекты можно было переопределить через свойства или конструктор.
Чем IoC лучше?

Про конфигурацию
«Если наш сервис требует настройки, его придется настраивать в каждом классе, который его использует.»
Что имел ввиду автор? Передавать константные параметры в конструктор? Чем тут IoC контейнер лучше фабрики и грамотно спроектированной структуры конфигурационного файла или даже объекта, который конфигурирует себя сам?]]> Wed, 24 Jun 2009 18:10:13 GMT timafyozzi