Comments 11
Спасибо за статью.
Небольшая критика.
Я слышал, что разрешение зависимостей по строковому имени — это каг бы не правильно.
Правильно это marker interface.
Что вы об этом думаете?
Небольшая критика.
Я слышал, что разрешение зависимостей по строковому имени — это каг бы не правильно.
Правильно это marker interface.
Что вы об этом думаете?
Всегда пожалуйста.
А для чего тут marker interface использовать?
Можно пример кода?
А для чего тут marker interface использовать?
Можно пример кода?
Действительно, marker interface это не ваш случай.
Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?
А строковые имена хороши для usecase типа ResolveAll. Чтобы вернулся массив всех объектов, реализующих IPersistence. Здесь мне кажется лучше без них.
Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?
А строковые имена хороши для usecase типа ResolveAll. Чтобы вернулся массив всех объектов, реализующих IPersistence. Здесь мне кажется лучше без них.
Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?
Полностью согласен. Ваш вариант лучше, т.к. в моем варианте мы часть ответственности IoC берем на себя.
Плюс в Вашем варианте можно при изменении конфигурации, после перерегистрации вызвать BuildUp для существующих объектов, что должно заменить в них реализации зависимостей.
Но пост писался как пример создания Unity Extension.
В плане доступности сервисов, тут есть варианты. Например, можно получать первый существующий сервис вот так:
Не очень эленантно, но все же. Также есть например вот такой вариант:
А за статью спасибо. Интересно.
IService svc1 = uc.Resolve<IService>("database");
IService svc2 = uc.Resolve<IService>("memory");
var svc = svc1 ?? svc2;
Не очень эленантно, но все же. Также есть например вот такой вариант:
var svc = uc.ResolveAll<IService>().FirstOrDefault(s => s != null);
А за статью спасибо. Интересно.
А что вы решили насчет написания статьи об использовании Unity по мотивам одного из предыдущих постов на Хабре?
Ну, я написал небольшой пост на эту тему. Возможно в скором будущем напишу еще.
Всегда пожалуйста.
Но не очень понял комментарий.
Нам не нужно получить «любую из существующих реализаций», нам нужно получить «реализацию, нужную в данный момент, в зависимости от условий о которых IoC не знает»
И Resolve не возвращает null, если такой реализации нет — будет exception.
Но не очень понял комментарий.
Нам не нужно получить «любую из существующих реализаций», нам нужно получить «реализацию, нужную в данный момент, в зависимости от условий о которых IoC не знает»
И Resolve не возвращает null, если такой реализации нет — будет exception.
Sign up to leave a comment.
Расширение возможностей Unity