Сильный аргумент для WF

Ответ 1

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

Функция удобства - это возможность создавать новые способы составления действий. Императивное программирование дает лишь ограниченный репертуар композиционных примитивов: в основном секвенирование, if-else и циклы. WF позволяет создавать собственные операторы композиции, такие как чередование, параллельное выполнение, первое сообщение и т.д. И, конечно же, у него есть сложный механизм компоновки построенных государственных машин.

Я говорю, что это удобная функция, потому что вы можете построить все эти операторы на императивном языке, таком как С#: на самом деле, как вы строите WF-операторы. Но WF упрощает использование и чтение пользовательских композиций, тогда как в С# вы быстро опускаетесь под градом лямбда-выражений. Поэтому, если у вас есть сложные требования к оркестровке, то есть, если способ объединения ваших действий более сложный, чем последовательности, if-else и loop, то WF может сделать вашу программу более удобной для выражения и понимания.

Уникальная особенность - долговечность. Здесь начинается книга Шукла и Шмидта, куда она возвращается. Обязательная программа, написанная на С# или VB, может работать в течение нескольких часов, дней, недель, если повезет, может быть, даже месяцев... но в конечном итоге IIS собирается циклически запускать пул приложений, или администраторы захотят установить последние обновления для системы безопасности, или кто-то собирается отключиться от шнура питания. Как тогда ваша программа помнит, "хорошо, у меня есть заказ на поставку от Unimaginative Company Names R Us, и я жду подтверждения кредита от Bank of Breadheads Inc., и когда я получу это, я могу отправить подтверждение электронная почта"?

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

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

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

Отказ от ответственности: Я не программист WF и никогда не строил реальную WF-систему. Я прихожу к этому с фона BizTalk и из того, что я читал о WF, поэтому эта оценка является своеобразной теоретической. Надеюсь, он все равно поможет!

Ответ 2

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

Прежде всего, вы просите убедительные причины использовать рабочий процесс. Это очень субъективный вопрос, а не связанная с ним технология. Вы можете найти в Интернете белые документы, указывающие на всевозможные успешные и безуспешные в этом отношении реализации рабочих процессов. Это независимо от технологии, решение, которое было сделано с использованием какого-то продукта X, можно было бы также сделать с использованием продукта Y. Глава из Shukla и Schmidt, безусловно, объясняет основы, но я не уверен, что это хорошая книга, показывающая, где и где как применить рабочий процесс.

Во-вторых, вы ищете книгу для обучения Windows Workflow Foundation. Первый вопрос - WF3 или WF4, поскольку они очень разные звери. Я буду считать WF4, потому что это заменит WF3, когда .NET 4 будет выпущен (сейчас действительно скоро), а начиная с WF3 в большинстве случаев не имеет большого смысла. Но поскольку WF3 никогда не был очень популярен, а книжный рынок не очень выгоден для большинства авторов, пока нет книг WF4. Я считаю, что Брюс Буковичс работает над новой версией своей книги Pro WF: Windows Workflow в .NET 3.5, в которой я нашел один из наиболее полезных WF3 книги. Пока что ничего нет, и вы застряли с крайне ограниченными документами на сайте msdn и блоге, вроде моего здесь. И, конечно, есть курсы, такие как this от DevelopMentor (примечание: бесстыдный плагин, поскольку я ведущий автор курса)

В этом ответе здесь я привел несколько аргументов, это может помочь вам.

Не совсем ответ на ваш вопрос, но я надеюсь, что все это будет по-прежнему полезно для вас.

Ответ 3

Это снова не прямой ответ, но это может быть полезно при поиске других ресурсов. Для меня это похоже на то, что WF довольно сильно моделируется концепциями, представленными в "Язык выполнения бизнес-процессов" (BPEL). Это std. существует гораздо дольше, чем WF, и любое использование BPEL должно дать вам представление о том, как использовать WF для.

Я не использовал WF, но когда немного поиграл с BPEL, и мне было трудно использовать его. Это было главным образом благодаря поддержке инструмента (я обнаружил, что плагин eclipse для визуального моделирования отсутствует). Когда вы сочетаете это с тем, что трудно прочитать код в XML по сравнению с "синтаксисом обычного языка программирования", BPEL не был жизнеспособным решением. Если WF имеет хороший визуальный инструмент, то эта проблема, по крайней мере, была решена.

Ответ 4

Хорошие причины: Визуальная проверка ваших бизнес-процессов. Вы даже можете заставить своего клиента - эксперта по домену - редактировать рабочий процесс с помощью конструктора; перезапустить приложение и запустить его без перекомпиляции

Хорошая книга: Брюс Букович И мой любимый любимый: PRO С# 2010 и .NET.NET Framework имеют отличную главу

Ответ 5

Я не знаю книги, посвященной этой теме. Тем не менее, я считаю, что часть привлекательности WF (или других продуктов рабочего процесса) заключается в том, что она вновь вводит в заблуждение парадигму, основанную на сообщениях, которая была заинтересована в оригинальных парнях OO (таких как Алан Кей).

Понятие переданного "сообщения" не сразу становится очевидным в WF. Однако понятие объектов, действующих как дискретные машины, есть.

Для удивительной (но несколько сумасшедшей) книги о состоянии OO см. Object Thinking by David West. И посмотрите здесь для обсуждения Алана Кей о том, что для него означает OO.