Когда использовать Windows Workflow Foundation? [закрыто]

154

Некоторые вещи проще реализовать вручную (код), но некоторые проще с помощью WF. Похоже, WF можно использовать для создания (почти) любого вида алгоритма. Поэтому (теоретически) я могу сделать всю свою логику в WF, но, вероятно, это плохая идея для всех проектов.

В каких ситуациях целесообразно использовать WF, и когда это усложнит ситуацию, чем это должно быть? Каковы плюсы и минусы / стоимость WF против кодирования вручную?

Sumrak
источник
3
Кажется, стоит отметить, что полностью переписан для версии 4.0, которая вышла после этих ответов.
Sclarson

Ответы:

125

Вам может понадобиться WF, только если выполняется одно из следующих условий:

  1. У вас длительный процесс.
  2. У вас есть процесс, который часто меняется.
  3. Вы хотите визуальную модель процесса.

Для получения более подробной информации см. Сообщение Пола Эндрю: чего использовать Windows Workflow Foundation?

Пожалуйста, не путайте и не связывайте WF с визуальным программированием любого рода. Это неправильно и может привести к очень плохим архитектурным / дизайнерским решениям.

Панос
источник
4
Что такое единица измерения для длительного процесса?
ivorykoder
5
@ivorykoder "процессы" (действительно рабочие процессы ), которые могут пережить перезапуски сервера, на котором он находится.
лобстерство
Если бы у меня были требования, которые удовлетворяли только # 1, этого было бы недостаточно, чтобы я выбрал WF. Однако, если бы требования включали № 2 и / или № 3, это было бы гораздо более сильным аргументом в пользу использования WF.
Мик
12
Я не могу устоять: вам может понадобиться WF, только если любое из следующего верно: ложь.
Ронни Оверби
84

Никогда. Вы, вероятно, пожалеете об этом:

  • Крутая кривая обучения
  • Сложно отлаживать
  • Сложно поддерживать
  • Не обеспечивает достаточную мощность, гибкость или прирост производительности, чтобы оправдать его использование
  • Может и будет повреждать состояние приложения, которое не может быть восстановлено

Единственный раз, когда я мог представить себе использование WF, - это если бы я хотел разместить дизайнер для конечного пользователя, а возможно, даже тогда.

Поверьте мне, ничто никогда не будет таким простым, мощным или гибким, как код, который вы пишете, чтобы делать именно то, что вам нужно. Держись подальше от WF.

Конечно, это только мое мнение, но я думаю, что оно чертовски хорошее. :)

Ронни Оверби
источник
27
-1 Я уважаю ваше мнение по этому поводу, но очень ценю профессиональное объяснение причины. я не вижу, как такой ответ помогает кому-либо
danfromisrael
9
Я написал этот ответ в день, когда я был зол на WF4. Я обновлю свой ответ проблемами, с которыми я столкнулся.
Ронни Оверби
5
Мы унаследовали половину завершенного проекта от консультанта, который использовал WF в качестве основы. Он был подвержен ошибкам, поврежденным рабочим процессам, которые не могут быть перезапущены, архаичной системе управления версиями, которая требует полной копии рабочего процесса для любых незначительных изменений, ужасающему сгенерированному коду и такому деликатному коду, что вы должны справиться с ним с помощью детских перчаток. , После 6 месяцев желтых экранов смерти мы списали весь WF и вместо этого использовали xml. Лучшее решение, которое мы когда-либо принимали.
Кевин Девоэ
10
Фраза: «Не обеспечивает достаточной мощности, гибкости или повышения производительности, чтобы оправдать его использование» , для меня достаточно. Спасибо вам за это.
Дэвид Тэнси
1
Ненавистникам нужно объяснять свою ненависть.
Ронни Оверби
46

Код, сгенерированный WF, неприятен. Ценность, которую приносит WF, заключается в визуальном представлении системы, хотя я еще ничего не видел (сейчас работает 6-7 проектов с WF, с которыми я был связан), где я бы не предпочел более простой проект с ручным кодированием. ,

craigb
источник
40

В общем, если вам не нужны функции сохранения и отслеживания (которые, на мой взгляд, являются основными функциями), вам не следует использовать Workflow Foundation.

Вот преимущества и недостатки Workflow Foundation, которые я извлек из своего опыта:

преимущества

  • Постоянство: если у вас будет много длительных процессов (например, дни, недели, месяцы), то рабочие процессы отлично подходят для этого. Свободные экземпляры рабочего процесса сохраняются в базе данных, поэтому она не использует память.
  • Отслеживание: WF предоставляет механизм для отслеживания каждого действия, выполняемого в рабочем процессе.
  • * Visual Designer: я поставил это как *, потому что я думаю, что это действительно полезно только для маркетинговых целей. Как разработчик, я предпочитаю писать код, а не соединять вещи визуально. И когда у вас есть не-разработчик, создающий рабочие процессы, вы часто сталкиваетесь с огромным запутанным беспорядком.

Недостатки

  • Модель программирования: вы действительно ограничены в возможностях программирования. Подумайте обо всех замечательных функциях C #, а затем забудьте о них. Простые одно или двухстрочные операторы в C # превращаются в довольно большие блоки действий. Это особенно болезненно для проверки входных данных. Сказав это, если вы действительно осторожны, чтобы сохранить только высокоуровневую логику в рабочих процессах и все остальное в C #, то это может не быть проблемой.
  • Производительность: рабочие процессы занимают большой объем памяти. Если вы развертываете много рабочих процессов на сервере, убедитесь, что у вас есть тонны памяти. Также помните, что рабочие процессы намного медленнее, чем обычный код C #.
  • Крутая кривая обучения, сложная для отладки: как уже упоминалось выше. Вы собираетесь потратить много времени на выяснение того, как заставить вещи работать, и нахождение наилучшего способа что-то сделать.
  • Несовместимость версий рабочего процесса: если вы развертываете рабочий процесс с постоянством, и вам необходимо внести изменения в рабочий процесс, старые экземпляры рабочего процесса больше не будут совместимы. Предположительно это исправлено в .NET 4.5.
  • Вы должны использовать выражения VB (.NET 4.5 допускает выражения C #).
  • Не гибкий: если вам нужны какие-то особые или специфические функции, не предоставляемые Workflow Foundation, приготовьтесь к большим трудностям. В некоторых случаях это может быть даже невозможно. Кто знает пока не попробуешь? Здесь много риска.
  • Службы WCF XAML без интерфейсов. Обычно со службами WCF вы разрабатываете интерфейс. Службы WCF XAML не позволяют гарантировать, что служба WCF XAML реализовала все в интерфейсе. Вам даже не нужно определять интерфейс. (насколько я знаю...)
Mas
источник
7
Большинство ваших недостатков просто не соответствуют действительности, возможно, вы недостаточно знакомы с WF. WF очень гибкий. Это позволяет вам писать собственные действия (действия кода), которые вы можете использовать в любом сценарии. Вам решать писать многоразовые действия. Представьте, что вы сможете предоставить GUI (приложение WPF с Workflow Designer Host) бизнес-консультантам вместе с набором действий. Теперь они могут изменять и перестраивать бизнес-логику в соответствии со своими потребностями, не требуя разработчиков и даже компилировать новое приложение.
Свен
3
А теперь представьте, что бизнес-консультант должен использовать вашего собственного дизайнера, но без Intellisense! Либо сверните свои собственные, либо вы должны использовать Visual Studio. Я также думаю, что бизнес-консультантам будет сложно даже понять некоторые понятия, такие как компенсация, отмена, обработка исключений. Также любая логика, которая является событием, дистанционно сложным, приведет к гигантскому рабочему процессу, который станет неуправляемым (о, и вам понадобятся тонны оперативной памяти для редактирования таких рабочих процессов). Вы правы, хотя тщательно продуманные пользовательские действия обеспечивают достаточную гибкость.
Мас
27

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

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

Теган Малхолланд
источник
11

Лично я не продан на WF. Эта полезность была для меня не такой очевидной, как другие новые технологии MS, такие как WPF или WCF.

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

обкрадывать
источник
7

Компания, в которой я сейчас работаю над созданием Windows Workflow Foundation (WF), и причины, по которым они решили его использовать, заключались в том, что правила часто менялись, и это заставляло бы их перекомпилировать различные библиотеки DLL и т. Д., И поэтому их решение было разместить правила в БД и вызвать их оттуда. Таким образом, они могут изменить правила и не должны перекомпилировать и перераспределять библиотеки и т. Д.

rae1
источник
21
Жаль, что обычные веб-службы и приложения не имеют файлов .config, не могут ни читать базы данных, ни читать XML, ни локальные файлы, содержащие правила, без перекомпиляции. Ой, подождите ...
Dour High Arch
6

Рабочие процессы Windows соблазняют некодирующих ИТ-менеджеров, BA и т.п., как и его двоюродный брат BizTalk, но на практике модульное тестирование, отладка и покрытие кода - это только три из многих ловушек. Вы можете преодолеть некоторые из них, но вы должны вкладывать значительные средства в достижение этого, тогда как с простым кодом вы просто получаете это. Если у вас действительно есть долгосрочное требование, то вам, вероятно, нужно что-то более сложное. Я слышал аргумент о возможности переноса новых файлов xaml в рабочую среду без повторной компиляции dll, но, честно говоря, время, которое потребляют рабочие процессы, можно было бы лучше использовать для улучшения непрерывной интеграции до такой степени, что скомпилированные развертывания не являются проблемой.

Оуайн Глиндер
источник
3

Я бы использовал его в любой среде, где мне нужно работать с рабочим процессом, однако при использовании его в сочетании с K2 или даже SharePoint 2007 мощь платформы действительно полезна. При разработке бизнес-приложений с участием специалиста по BI рекомендуется использовать платформу, что обычно имеет отношение только к оптимизации и улучшению бизнес-процессов.

Для справки: WF был разработан совместно с командой разработчиков K2, а новый K2 Blackpearl построен поверх WF, так же как и MOSS 2007 и механизмы рабочих процессов WSS 3.0.

BinaryMisfit
источник
2

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

sparksustc
источник
1

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

Кроме того, в тех случаях, когда у вас долго работают процессы, WF - это хороший технологический стек, который нужно использовать, когда вам нужно динамически обновлять процессы - без необходимости переустанавливать / скачивать или делать что-либо, просто добавьте новые файлы XAML в каталог, и ваша архитектура должна настроить версионность, чтобы удалить старый и использовать новый.

JohnChris
источник