Веские доводы в пользу WF

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

Удобная функция - это возможность создавать новые способы составления занятий. Императивное программирование предоставляет только ограниченный набор примитивов композиции: в основном последовательность, if-else и циклы. WF позволяет вам создавать собственные операторы композиции, такие как чередование выполнения, параллельное выполнение, первое после публикации и т. Д. И, конечно же, в него встроен сложный механизм композиции конечных автоматов.

Я говорю, что это удобная функция, потому что вы можете построить все эти операторы на императивном языке, таком как C #: на самом деле как вы строите операторы WF. Но WF упрощает использование и чтение пользовательских композиций, тогда как в C # вы быстро потеряете град лямбда-выражений. Поэтому, если у вас есть сложные требования к оркестровке - то есть, если способ согласования ваших действий сложнее, чем последовательности, if-else и циклы, - тогда WF может упростить выражение и понимание вашей программы.

Уникальной особенностью является долговечность . Вот откуда начинается книга Шуклы и Шмидта и к чему она постоянно возвращается. Обязательная программа, написанная на C # или VB, может работать часами, днями, неделями, если повезет, может быть, даже месяцами ... но в конечном итоге IIS будет циклически включать пул приложений, или администраторы захотят установить последние обновления безопасности. , или кто-то собирается споткнуться о шнур питания.Как тогда ваша программа запоминает: «Хорошо, у меня есть заказ на покупку от Unimaginative Company Names R Us, и я жду одобрения кредита от Bank of Breadheads Inc., и когда я его получу, я могу отправить подтверждение email "?

В обычной императивной программе, когда процесс умирает, состояние выполнения умирает вместе с ним. Вы можете начать новый процесс, но он начнется в начале программы. Конечно, вы можете создать базу данных и использовать ее для хранения таких флагов, как «получил заказ на покупку» и «получил одобрение кредита». Но теперь вам нужно написать код для конкретного приложения, чтобы сохранить и запросить состояние, а также вернуться в нужную точку программы в зависимости от этого состояния. И вам необходимо разработать новую базу данных и новую логику сохранения / восстановления / перехода для каждого отдельного долго работающего приложения.

Надежный рабочий процесс решает эту проблему. Если вы пишете свою программу как рабочий процесс действий, то WF позаботится о сохранении ее состояния, включая то, где оно находится в потоке выполнения. Машина, на которой запущена программа, может загореться и сжечь ваш центр обработки данных, но когда придет ответ от банка, WF разбудит вашу программу в другом центре обработки данных, и она начнет работать в нужном месте и с нужным данные.

Для меня это «веские аргументы» в пользу WF. Во многих случаях вам это не нужно: приложения достаточно недолговечны, так что сбой не является серьезной проблемой, а перезапуск с нуля является жизнеспособной стратегией восстановления.Но для приложений с длительным сроком службы, например, где вы можете управлять внешними системами, реагирование которых может занять несколько часов, или бизнес-процессами, в которых задействованы люди, которым могут потребоваться дни, чтобы ответить, надежность может оказаться решающим фактором для WF.

Заявление об ограничении ответственности: Я не программист WF и никогда не создавал реальных WF-систем. Я исхожу из опыта работы с BizTalk и из того, что я читал о WF, так что эта оценка носит своего рода теоретический характер. Надеюсь, это все равно поможет!