Comments 17
а чего под замком?
А давайте устроим конкурс «Кто доходчевее сможет объяснить, что такое Unity, DI, IoC итп...» :o)
Некто sse на самом деле давно пользуется Spring.NET и даже (гусары, молчать) его xml-config'ами, так что спрашивал он исключительно для того, чтобы уточнить границы применимости, бо волнует его этот вопрос с практической точки зрения. Layering он тоже успешно применяет и вам рекомендует, хоть и испытывает серьезные трудности с вбиванием это в головы коллегам по цеху.
Ну и как, понял границы?:)
В том посте мне не ответили, да еще и минуснули комментарий, хз почему так :) Из практики могу сказать, что для приложения до 5-10 тыс строк (c#) контейнер стоит применять, только если а) рафинированы слои и/или б) разработка предполагает наличие мощного test harness.
Для более крупного приложения _не использовать_ слои есть чуть менее, чем ритуальное самоубийство, и потому вопрос про контейнер там не ставится вовсе )
Для более крупного приложения _не использовать_ слои есть чуть менее, чем ритуальное самоубийство, и потому вопрос про контейнер там не ставится вовсе )
Вот бляха, и правда из-за этой галки пост в ленту не попал.
Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.
Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)
Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.
Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)
Ответ в начале 3й части про Unity вообще-то.
Послал так послал, ага. Попробую повторить. Вопрос был вот какой:
[начало вопроса] Если код
var svc = new MyService(10);
выливается в
var uc = new UnityContainer();
uc.RegisterType<IService, MyService>();
uc.RegisterType(new InjectionConstructor(10));
var svc = uc.Resolve();
то как в свете описанного примера будет выглядеть такой код, если его переписать на использование Unity:
var svc10 = new MyService(10);
var svc15 = new MyService(15);? [конец вопроса]
Таки нашел статью, несмотря на всё противодействие поиска на Хабре; ответа там нет. Вы можете прямо здесь ответить?
[начало вопроса] Если код
var svc = new MyService(10);
выливается в
var uc = new UnityContainer();
uc.RegisterType<IService, MyService>();
uc.RegisterType(new InjectionConstructor(10));
var svc = uc.Resolve();
то как в свете описанного примера будет выглядеть такой код, если его переписать на использование Unity:
var svc10 = new MyService(10);
var svc15 = new MyService(15);? [конец вопроса]
Таки нашел статью, несмотря на всё противодействие поиска на Хабре; ответа там нет. Вы можете прямо здесь ответить?
Цитирую:
Ситуация, в которой регистрируется несколько мэппингов одного типа поддается контролю когда нужно передать все зарегистрированные типы сервисов (то есть IService[]). Но что если нужно получить один конкретный сервис из контейнера? Для этого в Unity предусмотрена возможность давать объектам имена. Например, чтобы реализовать аналог вот этого кода
var svc10 = new MyService(10);
var svc15 = new MyService(15);
нужно зарегистрировать как раз “именные” мэппинги, а точнее:
var uc = new UnityContainer();
// регистрируем с именем
uc.RegisterType<IService, MyService>(«ten»,
new InjectionConstructor(new InjectionParameter(10)))
.RegisterType<IService, MyService>(«fifteen»,
new InjectionConstructor(new InjectionParameter(15)));
// получаем
var _10 = uc.Resolve(«ten»);
var _15 = uc.Resolve(«fifteen»);
Также, имеется возможность получить все зарегистрированные мэппинги. Делется это с помощью функции ResolveAll():
foreach (IService svc in uc.ResolveAll())
svc.DoSomething();
Ситуация, в которой регистрируется несколько мэппингов одного типа поддается контролю когда нужно передать все зарегистрированные типы сервисов (то есть IService[]). Но что если нужно получить один конкретный сервис из контейнера? Для этого в Unity предусмотрена возможность давать объектам имена. Например, чтобы реализовать аналог вот этого кода
var svc10 = new MyService(10);
var svc15 = new MyService(15);
нужно зарегистрировать как раз “именные” мэппинги, а точнее:
var uc = new UnityContainer();
// регистрируем с именем
uc.RegisterType<IService, MyService>(«ten»,
new InjectionConstructor(new InjectionParameter(10)))
.RegisterType<IService, MyService>(«fifteen»,
new InjectionConstructor(new InjectionParameter(15)));
// получаем
var _10 = uc.Resolve(«ten»);
var _15 = uc.Resolve(«fifteen»);
Также, имеется возможность получить все зарегистрированные мэппинги. Делется это с помощью функции ResolveAll():
foreach (IService svc in uc.ResolveAll())
svc.DoSomething();
Млять, извините, не ту статью смотрел ) Все нашел.
Тем не менее:
var uc = new UnityContainer();// регистрируем с именем
uc.RegisterType<IService, MyService>(«ten», new InjectionConstructor(new InjectionParameter(10)))
.RegisterType<IService, MyService>(«fifteen», new InjectionConstructor(new InjectionParameter(15)));
// получаем
var _10 = uc.Resolve<IService>(«ten»);
var _15 = uc.Resolve<IService>(«fifteen»);
куда более громоздко, чем:
var svc10 = new MyService(10);
var svc15 = new MyService(15);
Тем не менее:
var uc = new UnityContainer();// регистрируем с именем
uc.RegisterType<IService, MyService>(«ten», new InjectionConstructor(new InjectionParameter(10)))
.RegisterType<IService, MyService>(«fifteen», new InjectionConstructor(new InjectionParameter(15)));
// получаем
var _10 = uc.Resolve<IService>(«ten»);
var _15 = uc.Resolve<IService>(«fifteen»);
куда более громоздко, чем:
var svc10 = new MyService(10);
var svc15 = new MyService(15);
А вам не кажется что например просачивание того же IUnityContainer как инъецируемого параметра в класс Module это не есть хорошо? У меня например возникают сомнения даже когда я пишу [Dependency] перед свойствами в объектах доменной логики (а писать приходится).
Че-то не ушел мой комент. Отвечу еще раз.
1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.
2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.
Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.
Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.
1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.
2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.
Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.
Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.
Sign up to leave a comment.
Layers + Unity Container