Виндзорский центр WCF и печатные фабрики

Question

Мой вопрос имеет отношение к WCF и типизированным заводским возможностям, которые предоставляет Windsor. Я довольно плохо знаком с концепциями контейнера IoC и особенно с возможностями, но начал изучать его после оценки проекта, который мы написали некоторое время назад. Программа является многоуровневой и не очень хорошо тестируемой, поскольку внедрение зависимостей не везде реализовано. Проблема в том, что, поскольку он n-слойный, для правильного создания DI верхний слой будет отвечать за создание экземпляра чего-то, что будет использоваться, например, на 5 слоев вниз; поэтому я обратился к IoC.

Тем не менее, после прочтения многих статей SO и других сайтов, я столкнулся с парой проблем. Первоначально одной из основных проблем было отделение класса от физической реализации службы WCF, и я сделал это следующим образом:

service = ManagerService.IoC.Resolve<IGridSubmitWorkService>(new { binding = new BasicHttpBinding(), remoteAddress = new EndpointAddress(WorkerAddress) });

result = service.SubmitWorkUnit(out errorString, aWorkUnit);
ManagerService.IoC.Release(service);

Тем не менее, я нашел несколько упоминаний о том, как вы не должны использовать IoC.Resolve<>() и лучше использовать фабрики и средства WCF, чтобы убрать зависимость от вашего IoC container и что это шаблон поиска сервисов, который некоторые люди считают антишаблоном.

Моя проблема заключается в следующем: приведенные выше три строки кода решают почти все мои проблемы, но чтобы следовать правильным шаблонам, мне нужно вместо этого создать средство WCF, типизированную фабрику (которая будет заниматься предоставлением мне экземпляров класса, в котором используется этот код) и новый интерфейс для фабрики, и это похоже на чрезмерное проектирование и добавление ненужных усложнений в код только для того, чтобы угодить шаблону.

Вопрос 1: Есть ли что-то фундаментальное, что я здесь упускаю?

Вопрос 2: Как видно из кода, я вызываю непустой конструктор для веб-службы. Будет ли это так же просто, если я реализую средство WCF?

Вопрос 3: Можете ли вы указать мне достойный учебник по использованию средств WCF, поскольку я нашел объяснения в Виндзорской вики очень краткими и не очень полезными?

Спасибо

Answer 1

Q1. Да, я думаю, что пропущено что-то важное. В вашем трехстрочном примере все, что вы сделали, заменили одну зависимость реализации (ваш GridSubmitWorkService) на другую (ManagerService.IoC). Чтобы проиллюстрировать, почему бы не сделать это еще проще со следующим?

service = new GridSubmitWorkService(binding,remoteAddress);
result = service.SubmitWorkUnit();

Это еще проще, но оно имеет аппаратную зависимость реализации. Дело в том, что конструктор и внедрение свойств позволяют писать чистые компоненты, которые не должны понимать, как выполняется сантехника. Как в вашем коде, так и в моем коде этот принцип нарушается - компоненты управляют собственной сантехникой, и в большом приложении это становится очень болезненным, очень быстро. Вот почему многие считают ServiceLocator антишаблоном.

Название вашего сервисного локатора само по себе выдает игру. Это называется IoC - сокращение от Inversion of Control. Но когда вы посмотрите на структуру этих двух битов кода, вы ясно увидите, что ничего не было инвертировано - код выполняет почти одно и то же в обоих случаях, но ваш пример немного более абстрактен и запутан.

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

Q2. Любой достойный DI-контейнер основан на инжекторе конструктора. Использование Windsor WCF очень простое и поддерживает различные методы хостинга, поэтому такие вещи, как привязки и адреса, так или иначе обрабатываются правильно.

Q3. Здесь есть много информации, начиная от форумов и заканчивая вопросами на stackru.com, в дополнение к документам и вики Windsor. Я предлагаю задать конкретный вопрос, если есть что-то, что вы не можете решить.