Windows Workflow Foundation или контейнер IoC + внедрение зависимостей?

Я пытаюсь понять внутреннее устройство основы рабочего процесса Windows. Итак, у нас есть некоторые программные компоненты, и мы объединяем их в виде рабочего процесса, будь то последовательный рабочий процесс на основе условий или рабочий процесс конечного автомата. Теперь я думаю (я могу ошибаться здесь), что то же самое не относится к IoC + Dependency Injection (через Unity или Spring.net). Когда что использовать ?? Я вообще правильно думаю ??

Есть ли проблема с моим вопросом ?? Прошло 2 часа без ответа, это так не похоже на StackOverflow

— 05.01.2009 22:33

Лично я не понимаю вопроса. «… что то же самое не относится к…» что это «то же самое» здесь? Что они могут быть последовательными или сатитационной машиной? (В данном случае, я думаю, ответ будет отрицательным.) Предлагаю перефразировать вопрос.

— 06.01.2009 12:45

.net dependency-injection inversion-of-control workflow-foundation

05.01.2009 19:36

Стоит ли изучать PHP в 2026-2027 годах?

Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией

В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.

Приемы CSS-макетирования - floats и Flexbox

Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...

Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest

В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...

Концепция локализации и ее применение в приложениях React ⚡️

Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...

Пользовательский скаляр GraphQL

Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...

1 870

Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Не совсем уверен, что понимаю вопрос, но все равно попробую.

WF не использует контейнер IOC. Он использует шаблон ServiceLocator, в котором вы добавляете зависимости к среде выполнения рабочего процесса, локатору служб и действиям рабочего процесса и извлекаете эти службы из среды выполнения рабочего процесса.

Шаблоны ServiceLocator и IOC похожи и имеют одну и ту же цель в разделении зависимостей. Apporach отличается, хотя в контейнере IOC, проталкивающем зависимости, в то время как ServiceLocator используется для извлечения зависимостей.

Надеюсь, это ответит на ваш вопрос, и если нет, я бы попытался перефразировать исходный вопрос.

06.01.2009 16:48

Я также боролся с тем, как использовать компоненты, предоставляемые и обслуживаемые моим контейнером IOC, из рабочих процессов. Как указано в другом ответе, экземпляры рабочего процесса хотят использовать локатор служб для извлечения служб из среды выполнения вместо внедрения зависимостей.

Простой способ преодолеть этот пробел - извлечь зависимости из контейнера IOC во время настройки среды выполнения WF, а затем использовать AddService, чтобы поместить их в среду выполнения. Ваши рабочие процессы могут переопределять OnActivityExecutionContextLoad и использовать метод GetService у поставщика услуг, чтобы выловить их обратно из среды выполнения и поместить их в общедоступные свойства [NonSerialized] рабочего процесса. Затем у вас будет доступ к услугам из кодовых действий и т. д.

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

25.04.2009 02:17