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

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

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

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

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

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

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

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

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

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

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

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

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

В общем, если вам не нужны функции сохранения и отслеживания (которые, на мой взгляд, являются основными функциями), вам не следует использовать 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 реализовала все в интерфейсе. Вам даже не нужно определять интерфейс. (насколько я знаю...)

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

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

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

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

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

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

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

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

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

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

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