А можно по конкретнее по первому вопросу? В каких случаех? Зачем? почему не сервис локатор. Могу позвонить Вам... если писать в лом
поконкретней ну как - подключаем сборки, пишем конфиги и вперед. зачем - тут тоже все обычно - не хватает наглости вписать красивые слова в резюме без использования в реальных проектах и ума понять что красивые слова хорошо работают только для текнолоджи евангелистов - затем и используется.
А можно по конкретнее по первому вопросу? В каких случаех? Зачем? почему не сервис локатор. Могу позвонить Вам... если писать в лом
поконкретней ну как - подключаем сборки, пишем конфиги и вперед. зачем - тут тоже все обычно - не хватает наглости вписать красивые слова в резюме без использования в реальных проектах и ума понять что красивые слова хорошо работают только для текнолоджи евангелистов - затем и используется.
Ну когда то помню в нете очень много обсуждали тему что лучше типа IoC или SL, вроде как с SL намного меньше конфигов надо писать. Большой проект щас без IoC написать очень сложно, но и разобраться в существующем спринг-конфиге тоже не просто
Думаю это на любителя, но по крайней мере IoC намного больше распространен щас + куча готовых фреймворков.
Привет!
1. Практикую DDD, придерживаюсь SOLID principles, соответственно использую IoC and DI повсеместно.
2. Почти все так или иначе используют, но может не знают что это так называется Передаете в констурктор класса абстракцию (скажем типа интерфейс) или имеете public свойство типа интерфейс с setter-ом - уже DI.
3. Для использования IoC and DI фреймфорк не обязателен, но если очень хочется, то: Unity, Autofac, Castle Windsor, Spring, StructureMap, Ninject. Сам использовал Unity, StructureMap, Castle Windsor, Spring.
Spring - в топку (много XML и нет code fluent config).
Unity - хорошо, хорошая документация
StructureMap - очень хорошо, но мало документации (во всяком случае было на тот момент когда использовал), доки плохо структурированы.
Castle Windsor - отлично
А с точки зрения производительности что можете сказать?
Я не замерял, но вот тут кто-то замерял. Вообще в действительно узких местах можно подумать о других механизмах конструирования объектов, а в целом по приложению я не думаю что незначительная разница в производительности контейнеров должна влиять на выбор. Я бы больше напрягался по поводу неоправданного использования IoC-контейнеров в небольших и средних (ближе к небольшим) приложениям где они не упрощают вещи, а только усложняют жизнь и поддерживаемость кода.
Comment