Pull to refresh

Comments 24

Уточните пожалуйста синтаксис регистрации через registry
public RegisterByRegister() {
var registry = new Registry();
registry.ForConcreteType();
registry.ForConcreteType();
Не понял вопроса, если честно. Можете более подробно рассказать, в какую сторону мне углубиться при ответе.
К Registry применимы все методы описанные в статье, когда идет регистрация через Container.
Извиняюсь, парсер съел < > даже независимо от того что я поместил их в блок code.
при регистрации через Registry у вас в примере не очень понятный синтаксис — мне кажется это копипаста и не исправлена (где интерфейс а где имплементация). Ну или если там все правильно — поясните что к чему биндится в таком синтаксисе. Они действительно биндятся одним и тем же методом?
Да, они действительно регистрируются одним методом. Например, вы хотите создать класс настроек или чего-нито в этом духе и интерфейс к нему не хотите делать потому что незачем. Эдакий статичный класс. Тогда регистрировать класс можно по его типу.
Поясните пожалуйста, что на что вот этими двумя строками регистрируется
registry.ForConcreteType<Class1>();
registry.ForConcreteType<Class2>();
Здесь регистрируется класс Class1 и Class2 как есть, конкретные реализации конкретых классов. Т.е. после регистрации их можно будет вызвать как
ObjectFactory.GetInstance(typeof(Class1)) и получить Class1
точно так же можно поступить для класса Class2.

Согласен, что это редкая ситуация, но тем не менее она имеет место быть.
спасибо

пара вопросов
для winphone/silverlight работает?
property injection/ constructor params injection есть?
для winphone/silverlight работает?

Нет.

property injection/ constructor params injection есть?

Да, будет рассказано далее очень скоро. Оставайтесь на связи =)
А своими словами сравнить с Unity не можете?

Берем ваш список достоинств:

«Настройка с помощью DSL»
Это не DSL, это fluent-интерфейс. В Unity из коробки нет fluent, но обычный код регистрации ничем не хуже. Сравниваем.

StructureMap:

new Container(x => {
x.For().Use();
x.For().Use();
});

Unity:

var container = new UnityContainer();
container.RegisterType()
container.RegisterType()

Что-то я не вижу явной разницы.

«Очень гибкая настройка всего»
Чего именно, например?

«Простота конечного использования»
Сравниваем.

StructureMap:

container.GetInstance();

Unity:

container.Resolver();

Кстати, а билдап в StructureMap есть?

«Возможности для проверки внутренних связей»
Поясните?

«Поддержка тестирования out-of-the-box»
А в чем это выражается? в Inject? Какое-то это странное поведение. Можете привести сценарий, зачем это надо?

Я обычно контейнер для тестирования сразу собираю правильный (а еще чаще стараюсь не использовать для тестирования контейнер, а передавать зависимости явно).

(В Unity это можно реализовать как через повторную регистрацию, так и через переопределение на резолве)
1. DSL — это условное название. Считайте, что это DSL, реализованный с помощью Fluent-выражений.

2. Гибкая настройка всего, что касается DI, но, я бы сказал, что это качество всех современных IoC-тулов.

3. Билдап, конечно, есть.

4. Поддержка тестирования — возможно, имелся в виду AutoMocker.

5. «а еще чаще стараюсь не использовать для тестирования контейнер, а передавать зависимости явно»
В точку. Нечасто контейнер нужен для тестирования как такового.
Да, да, вы правы насчет fluent интерфейса, что-то меня постоянно одно на другое клинит.
Ох, сравнение с Unity будет не менее эпичным чем этот опус (в цельном варианте). И сравнение этих фреймворков вызывает не меньшие холивары, чем Win vs *nix, Google vs MS и так далее. Лично у меня не сложилось с Unity, поэтому элемент предвзятости будет в любом случае, тут уж ничего не поделаешь.

Насчет простоты и гибкой настройки все предубеждения от того, что я видел наверно не самый лучший код по работе с Unity и настройка в xml файлах. Так что после этого StructureMap выглядит лучом солнца.

Кстати, а билдап в StructureMap есть?

Есть

Возможности для проверки внутренних связей

StructureMap можно попросить проверить корректность его настройки. Т.е. он попробует построить и разрешить все методы и свойства, и классы которые у него содержаться внутри.
Так же можно пользоваться методом WhatDoIHave, который наглядно покажет всё, что в нем зарегистрировано.

Поддержка тестирования out-of-the-box

Нет, это не только Inject. StructureMap интегрируется с RhinoMock и с Moq, позволяет писать тесты лаконичнее.

Я обычно контейнер для тестирования сразу собираю правильный (а еще чаще стараюсь не использовать для тестирования контейнер, а передавать зависимости явно).

Do the right thing right
+1

Сам очень люблю и использую в качестве основного DI-контейнера именно StructureMap, но такое заявление:
«самым удобным, гибким и естественным является StructureMap»- слишком уж громкое.

Да, мне тоже нравится Fluent-синтаксис, реализованный с помощью лямбда-выражений, все очень понятно и юзабельно.

Но, поскольку, приходилось использовать и другие в работе — Autofac и Ninject, по сути, ничем не уступают. Не знаю насчет Unity, но что-то мне подсказывает, что там дела не хуже. В общем, тут вопрос личных предпочтений.

Насчет сканирования и конкуренции MEF — согласен, именно это и используем для «discovery and composition» вместо MEF.
Сам очень люблю и использую в качестве основного DI-контейнера именно StructureMap, но такое заявление:
«самым удобным, гибким и естественным является StructureMap»- слишком уж громкое.

Это я в порыве страсти. Вводное слово может ведь быть чуть более эмоциональным? ;)
Конечно, может)

Кстати, меня немного беспокоит дальнейшая судьба StructureMap, хотя, впрочем, думаю, что в комьюнити есть кому перехватить эстафету Джереми.
Ох, меня тоже обеспокоил данный пост, и я был очень расстроен, что Джерми переключается на другой проект, но он упоминает людей с горящими глазами, так что надежда есть.
Пробовал писать ему несколько раз, но ответа никакого нет ((
А можно годную ссылку почитать об IoC в общих чертах, и для чего это вообще нужно и где стоит их применять.
Это нужно для удобства разработки в команде, поддержка программы несколько упрощается за счет малой связности компонентов, и конечно для тестов это очень помогает, так как можно ловко работать с отдельно взятыми объектами. А работать с ними так можно потому, что у них нет внутренних жестких зависимостей (на другие классы), которые удалены с помощью IoC.

ru.wikipedia.org/wiki/Внедрение_зависимости
habrahabr.ru/blogs/net/62830/
www.handcode.ru/2010/02/blog-post.html
«поддержка программы несколько упрощается»

Несколько? :)
It depends
При наличии тестов — сильно упрощается.
Если все максимально развязано, то поддерживать становиться сложно.

Пробовал исследовать API к TFS, так там много чего построено на сервисах, которые надо получить по типу или интерфесу, и их, мягко говоря, сложно найти. Так что это, как и любая технология, палка о двух концах: можно облегчить себе жизнь, а можно превратить ее в ад.
А TFS это эталон?:) Шутка, конечно)
Ну, скажем так, при правильном и своевременном (Right Tool For The Right Job) использовании он только упрощает и сильно.
Лучший IoC. IoC, который ты понимаешь от и до. А уж SM или NJ или Unity. Какая разница, что в коробке? Всё всегда решает задача. Лично мой опыт такой, использовал Unity, внимательно исследовал NJ и SM на предмет, а не лучше ли использовать их. Сделал вывод, что надо писать свой IoC. Что с успехом и проделал. И вот уже за больше полутора лет моё мнение не изменилось. Оговорюсь, это лично моё мнение!
Ну, понять SM от и до проблем не доставило.
Все, что я сделал — это абстракцию вокруг контейнера, который способен «резолвить» (с CommonServiceLocator), регистрировать — IServiceRegistrar, инжектить — IServiceInjector, и сканировать — IServiceDiscovery.
Я не утверждаю, что он сложен. Твою бы голову взять да поставить каждому, вот тогда все всё понимали бы одинаково) Я утверждаю, что надо понимать IoC, который ты используешь.
Only those users with full accounts are able to leave comments. Log in, please.