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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Недостатки

• Программная модель:Вы действительно ограничены в возможностях программирования.Подумайте обо всех замечательных функциях, которые есть у вас в C #, а затем забудьте о них.Простые одно- или двухстрочные операторы в C # превращаются в довольно большой блок действий.Это особенно сложно при проверке входных данных.Сказав это, если вы действительно будете осторожны, чтобы сохранить только высокоуровневую логику в рабочих процессах, а все остальное в C #, то это может и не быть проблемой.
• Производительность:Рабочие процессы занимают большой объем памяти.Если вы развертываете много рабочих процессов на сервере, убедитесь, что у вас достаточно памяти.Также имейте в виду, что рабочие процессы выполняются намного медленнее, чем обычный код на C #.
• Крутая кривая обучения, трудная для отладки:Как упоминалось выше.Вы потратите много времени на то, чтобы понять, как заставить все работать, и на то, чтобы найти наилучший способ что-то сделать.
• Несовместимость версий рабочего процесса:Если вы развертываете рабочий процесс с сохраняемостью и вам необходимо вносить обновления в рабочий процесс, старые экземпляры рабочего процесса больше не совместимы.Предположительно, это исправлено в .NET 4.5.
• Вы должны использовать выражения VB (.NET 4.5 допускает выражения на C #).
• Не гибкий:Если вам нужна какая-то особая функциональность, не предоставляемая Workflow Foundation, приготовьтесь к большим трудностям.В некоторых случаях это может быть даже невозможно.Кто знает, пока ты не попробуешь?Здесь очень много риска.
• Службы WCF XAML без интерфейсов:Обычно с помощью служб WCF вы разрабатываете интерфейс.С помощью служб WCF XAML вы не можете гарантировать, что служба WCF XAML реализовала все в интерфейсе.Вам даже не нужно определять интерфейс.(насколько я знаю...)

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

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

Answer 11

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

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