Comments 24
Уточните пожалуйста синтаксис регистрации через registry
public RegisterByRegister() {
var registry = new Registry();
registry.ForConcreteType();
registry.ForConcreteType();
Не понял вопроса, если честно. Можете более подробно рассказать, в какую сторону мне углубиться при ответе.
К Registry применимы все методы описанные в статье, когда идет регистрация через Container.
К Registry применимы все методы описанные в статье, когда идет регистрация через Container.
Извиняюсь, парсер съел < > даже независимо от того что я поместил их в блок code.
при регистрации через Registry у вас в примере не очень понятный синтаксис — мне кажется это копипаста и не исправлена (где интерфейс а где имплементация). Ну или если там все правильно — поясните что к чему биндится в таком синтаксисе. Они действительно биндятся одним и тем же методом?
при регистрации через Registry у вас в примере не очень понятный синтаксис — мне кажется это копипаста и не исправлена (где интерфейс а где имплементация). Ну или если там все правильно — поясните что к чему биндится в таком синтаксисе. Они действительно биндятся одним и тем же методом?
Да, они действительно регистрируются одним методом. Например, вы хотите создать класс настроек или чего-нито в этом духе и интерфейс к нему не хотите делать потому что незачем. Эдакий статичный класс. Тогда регистрировать класс можно по его типу.
Поясните пожалуйста, что на что вот этими двумя строками регистрируется
registry.ForConcreteType<Class1>();
registry.ForConcreteType<Class2>();
registry.ForConcreteType<Class1>();
registry.ForConcreteType<Class2>();
Здесь регистрируется класс Class1 и Class2 как есть, конкретные реализации конкретых классов. Т.е. после регистрации их можно будет вызвать как
ObjectFactory.GetInstance(typeof(Class1)) и получить 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 это можно реализовать как через повторную регистрацию, так и через переопределение на резолве)
Берем ваш список достоинств:
«Настройка с помощью 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. «а еще чаще стараюсь не использовать для тестирования контейнер, а передавать зависимости явно»
В точку. Нечасто контейнер нужен для тестирования как такового.
2. Гибкая настройка всего, что касается DI, но, я бы сказал, что это качество всех современных IoC-тулов.
3. Билдап, конечно, есть.
4. Поддержка тестирования — возможно, имелся в виду AutoMocker.
5. «а еще чаще стараюсь не использовать для тестирования контейнер, а передавать зависимости явно»
В точку. Нечасто контейнер нужен для тестирования как такового.
Да, да, вы правы насчет fluent интерфейса, что-то меня постоянно одно на другое клинит.
Ох, сравнение с Unity будет не менее эпичным чем этот опус (в цельном варианте). И сравнение этих фреймворков вызывает не меньшие холивары, чем Win vs *nix, Google vs MS и так далее. Лично у меня не сложилось с Unity, поэтому элемент предвзятости будет в любом случае, тут уж ничего не поделаешь.
Насчет простоты и гибкой настройки все предубеждения от того, что я видел наверно не самый лучший код по работе с Unity и настройка в xml файлах. Так что после этого StructureMap выглядит лучом солнца.
Есть
StructureMap можно попросить проверить корректность его настройки. Т.е. он попробует построить и разрешить все методы и свойства, и классы которые у него содержаться внутри.
Так же можно пользоваться методом WhatDoIHave, который наглядно покажет всё, что в нем зарегистрировано.
Нет, это не только Inject. StructureMap интегрируется с RhinoMock и с Moq, позволяет писать тесты лаконичнее.
Do the right thing right
+1
Ох, сравнение с 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.
«самым удобным, гибким и естественным является StructureMap»- слишком уж громкое.
Да, мне тоже нравится Fluent-синтаксис, реализованный с помощью лямбда-выражений, все очень понятно и юзабельно.
Но, поскольку, приходилось использовать и другие в работе — Autofac и Ninject, по сути, ничем не уступают. Не знаю насчет Unity, но что-то мне подсказывает, что там дела не хуже. В общем, тут вопрос личных предпочтений.
Насчет сканирования и конкуренции MEF — согласен, именно это и используем для «discovery and composition» вместо MEF.
Сам очень люблю и использую в качестве основного DI-контейнера именно StructureMap, но такое заявление:
«самым удобным, гибким и естественным является StructureMap»- слишком уж громкое.
Это я в порыве страсти. Вводное слово может ведь быть чуть более эмоциональным? ;)
Конечно, может)
Кстати, меня немного беспокоит дальнейшая судьба StructureMap, хотя, впрочем, думаю, что в комьюнити есть кому перехватить эстафету Джереми.
Кстати, меня немного беспокоит дальнейшая судьба StructureMap, хотя, впрочем, думаю, что в комьюнити есть кому перехватить эстафету Джереми.
А можно годную ссылку почитать об IoC в общих чертах, и для чего это вообще нужно и где стоит их применять.
Это нужно для удобства разработки в команде, поддержка программы несколько упрощается за счет малой связности компонентов, и конечно для тестов это очень помогает, так как можно ловко работать с отдельно взятыми объектами. А работать с ними так можно потому, что у них нет внутренних жестких зависимостей (на другие классы), которые удалены с помощью IoC.
ru.wikipedia.org/wiki/Внедрение_зависимости
habrahabr.ru/blogs/net/62830/
www.handcode.ru/2010/02/blog-post.html
ru.wikipedia.org/wiki/Внедрение_зависимости
habrahabr.ru/blogs/net/62830/
www.handcode.ru/2010/02/blog-post.html
«поддержка программы несколько упрощается»
Несколько? :)
Несколько? :)
It depends
При наличии тестов — сильно упрощается.
Если все максимально развязано, то поддерживать становиться сложно.
Пробовал исследовать API к TFS, так там много чего построено на сервисах, которые надо получить по типу или интерфесу, и их, мягко говоря, сложно найти. Так что это, как и любая технология, палка о двух концах: можно облегчить себе жизнь, а можно превратить ее в ад.
При наличии тестов — сильно упрощается.
Если все максимально развязано, то поддерживать становиться сложно.
Пробовал исследовать API к TFS, так там много чего построено на сервисах, которые надо получить по типу или интерфесу, и их, мягко говоря, сложно найти. Так что это, как и любая технология, палка о двух концах: можно облегчить себе жизнь, а можно превратить ее в ад.
Лучший IoC. IoC, который ты понимаешь от и до. А уж SM или NJ или Unity. Какая разница, что в коробке? Всё всегда решает задача. Лично мой опыт такой, использовал Unity, внимательно исследовал NJ и SM на предмет, а не лучше ли использовать их. Сделал вывод, что надо писать свой IoC. Что с успехом и проделал. И вот уже за больше полутора лет моё мнение не изменилось. Оговорюсь, это лично моё мнение!
Ну, понять SM от и до проблем не доставило.
Все, что я сделал — это абстракцию вокруг контейнера, который способен «резолвить» (с CommonServiceLocator), регистрировать — IServiceRegistrar, инжектить — IServiceInjector, и сканировать — IServiceDiscovery.
Все, что я сделал — это абстракцию вокруг контейнера, который способен «резолвить» (с CommonServiceLocator), регистрировать — IServiceRegistrar, инжектить — IServiceInjector, и сканировать — IServiceDiscovery.
Sign up to leave a comment.
StructureMap — краткий справочник для работы (1/3)