Коли користуватися 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, який я зібрав зі свого досвіду:

Переваги

• Наполегливість: Якщо у вас буде багато тривалих процесів (думайте, дні, тижні, місяці), робочі потоки відмінно підходять для цього. Непрацюючі екземпляри робочого процесу зберігаються в базі даних, щоб вона не використовувала пам'ять.
• Відстеження: 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 Workflows спокушають ІТ-менеджерів, що не кодують, BA і тому подібне, як і її двоюрідний брат BizTalk, але на практиці тестування блоків, налагодження та покриття коду - лише три з багатьох підводних каменів. Ви можете подолати деякі з них, але вам доведеться вкладати великі кошти в досягнення цього, тоді як з простим кодом ви просто це отримуєте. Якщо ви справді маєте давню вимогу, то, напевно, вам знадобиться щось більш складне. Я чув аргумент про те, що можна скидати нові файли xaml у виробництво без перекомпіляції dlls, але, чесно кажучи, час, який витратять Workflows, можна краще використати для вдосконалення вашої постійної інтеграції до того моменту, коли компільовані розгортання не є проблемою.

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

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

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

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

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