Зачем использовать Windows Workflow?
В чем преимущество использования Windows Workflow Foundation (WF) по сравнению с развертыванием собственной среды рабочего процесса?
Из того, что я могу сказать, WF предоставляет только довольно простой движок времени выполнения, набор классов и схему (на основе XAML) для определения рабочих процессов. Все сложные вещи, такие как постоянство, обеспечение хост-процесса для среды выполнения и реализация распределенных рабочих процессов (по процессам), оставлены на ваше усмотрение.
Плюс к этому есть необходимость обучения использованию WF... если бы мы создали нашу собственную среду рабочего процесса, мы бы просто использовали навыки, которые уже есть у всех разработчиков (C#, XML, SQL и т. Д.).
Я видел этот блог от евангелиста MS, который пытается объяснить, почему мы должны использовать WF:
ИМО не убедителен, потому что просто заявляет, что помогает "продуктивности разработчиков", признавая, что разработчики могут делать свои собственные.
Может ли кто-нибудь из умных людей придумать лучшую причину?
РЕЗЮМЕ ОТВЕТОВ, ДАННЫХ НИЖЕ:
Я думаю, что наиболее убедительная причина заключается в том, что использование стандартизированной платформы рабочего процесса, такой как WF (в отличие от собственной), позволит вам использовать текущие и будущие инструменты, такие как Visual Designer, предоставляемые MS и третьими лицами.
Кроме того, поскольку он является частью MS-стека технологий, основанных на.NET, он, вероятно, будет иметь лучший путь интеграции / миграции с будущими технологиями MS (такими как Azure).
Наконец, число разработчиков с опытом работы в WF будет увеличиваться (поскольку это будет полезно для их карьеры), превращая его в базовый товарный навык, такой как SQL или HTML, что означает, что станет легче находить людей, которые могут начать работать с ним минимальное время разгона.
6 ответов
Выбор WF требует некоторой оценки, и я постараюсь предоставить здесь довольно полный список преимуществ и недостатков. Имейте в виду, что если вы собираетесь использовать WF, не используйте ничего, кроме WF4+, потому что оно было переписано и значительно проверено по сравнению с его предшественниками.
Pros
- Стоимость
- гибкость
- долговечность
- Distributability
- Будущее
Стоимость
Стоимость WF важно учитывать при сравнении с другими путями. Эти пути могут включать в себя BizTalk, инфраструктуру с открытым исходным кодом, такую как Objectflow, или даже свою собственную. Имейте в виду, что если вам не нужно что-то значительно упрощенное, то каждый раз кататься по-своему будет самым дорогим подходом. Так что, если вам нужна значительная часть функциональности, но также требуется контроль над исходным кодом, я бы порекомендовал инфраструктуру с открытым исходным кодом.
гибкость
WF является очень гибкой средой по сравнению с такой средой, как BizTalk. В WF вы можете писать свои собственные пользовательские действия и делать то, что вам нужно делать за пределами фреймворка - это действительно дает вам необходимую мощность.
долговечность
WF включает в себя очень мощный каркас долговечности. Он долговечен в том смысле, что состояние рабочего процесса можно сохранить, рабочий процесс можно перевести в режим ожидания (для сохранения ресурсов), а затем вызвать его позже. Но эта долговечность идет намного дальше, потому что она уже настроена на долговечность во всей ферме. Другими словами, рабочий процесс может быть запущен на одном хосте, сохранен, а затем вызван на другом хосте.
Предполагается, что рабочие процессы размещаются через веб-службу (т.е. WorkflowService).
Distributability
WF уже настроен для распределения по ферме хостов.
Предполагается, что рабочие процессы размещаются через веб-службу (т.е. WorkflowService).
Будущее
WF является заменяющим механизмом оркестровки для BizTalk и фактически разрабатывается теми же людьми, которые создавали BizTalk. Поэтому у WF большое будущее в стеке Microsoft. Фактически, сейчас Microsoft работает над созданием отдельных компонентов, чтобы заменить каждую функцию BizTalk на компоненты. Например, Windows Server AppFabric (а точнее плагин для IIS) - это замена служб мониторинга, существующих сегодня в BizTalk.
Почему Microsoft делает это? Потому что BizTalk не очень хорошо подходит для облака, потому что это одна массовая установка, тогда как компоненты, которые они создают, могут быть развернуты в облачном решении.
Cons
- гибкость
- мониторинг
гибкость
Гибкость WF также может быть ее ловушкой, потому что иногда вам не нужна гибкость, которую она обеспечивает, и, таким образом, вы тратите больше времени на создание материала, который вы хотели бы просто включить. Иногда вам нужна структура, которая делает много предположений и, возможно, работает вместо соглашения (например, MVC). Однако, вообще говоря, я обнаружил, что это не так при соединении инфраструктуры WF4 с расширениями с открытым исходным кодом, предоставленными Роном Джейкобсом.
мониторинг
Мониторинг ВФ еще очень молод, и это самая большая ошибка. Однако со временем это будет происходить очень быстро, а тем временем вы сможете создавать свои собственные инструменты мониторинга с настраиваемыми механизмами отслеживания.
Ресурсы
Ваш лучший ресурс - Рон Джейкобс. Я никогда не встречал кого-то, кто так хотел бы помочь сообществу разработчиков, которые должны использовать фреймворки Microsoft, чем он. Поверьте мне, он предоставил огромное количество информации о WF по многочисленным каналам, просто зайдите в Google и проверьте это.
Основные причины, по которым я склоняюсь к использованию WF поверх другой среды рабочего процесса:
- Microsoft поддерживает его как основную часть инфраструктуры, поэтому его можно / будет легче интегрировать в другие технологии, такие как облачные приложения Sharepoint и Azure.
- Инструментарий, скорее всего, улучшится и станет еще лучше в следующих нескольких версиях, что должно повысить производительность труда разработчиков.
Короткий ответ: это бесплатно, и это делает работу. Если вы можете создать лучшую платформу для управления рабочим процессом и хотите тратить на нее свое время, обязательно сделайте это. Но учтите, что ваше время стоит денег, так сколько денег вы готовы посвятить созданию более совершенной основы для управления рабочим процессом? Я мог видеть, что становится дороже.
Кроме того, я почти уверен, что постоянство (на диск или SQL) обрабатывается из коробки.
Мне приходилось создавать на рабочем месте действия Workflow, и я даже не могу сказать вам ответ.
Одной не очень веской причиной является то, что недопустимые значения / входные данные могут быть определены и отклонены во время разработки для диаграмм рабочего процесса, и поэтому ошибки времени компиляции в основном не существуют (при условии, что весь этот написанный вами код не содержит ошибок времени компиляции).
В Visual Studio есть довольно неплохая дизайнерская поддержка, которую я бы предпочел не запускать для себя, и это фреймворк, поддерживаемый кем-то другим, а не мной, что означает, что кто-то исправляет ошибки архитектуры и выполняет основное тестирование, оставляя меня для тестирования только мой рабочий процесс. Я имею в виду, я мог бы бросить свои собственные версии вызовов GDI+, но я бы не хотел. То же самое касается моей собственной платформы сериализации, анализатора XML или какого-либо другого элемента.NET Framework.
Когда дело доходит до этого, эти вещи предоставляются в качестве инструментария. Выберете ли вы инструмент или нет, полностью зависит от решаемой проблемы, пригодности инструмента и времени и ресурсов, которые у вас есть для достижения цели.
Это новая технология Или вы можете сказать, что ее последняя версия обещает постоянно обновлять функции.
Он уважает предыдущую рабочую среду и использует ее и добавляет те функции, которые очень полезны при разработке долгосрочных программ (больших проектов).
Он предоставляет все эти возможности непосредственно в руки разработчика, который ранее работал сзади, не имея взаимодействия между концепциями внутреннего ядра и программистом.
Да, это немного сложнее, но также дает больше возможностей программисту.
Вы можете ожидать лучших рамок и функций в ближайшем будущем. Это будущее программирования, поэтому лучше начать его изучать сегодня.