Сильный случай для WF - PullRequest
       14

Сильный случай для WF

38 голосов
/ 21 марта 2010

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

Кто-нибудь знает какую-нибудь книгу, которая действительно обосновывает путь Workflow? Книга должна (i) хорошо научить WF и (ii) показать с помощью соответствующих сценариев использования, что WF сделала реализацию проще, чем если бы мы только что делали наше обычное прямое кодирование.

Я буду признателен.

Ответы [ 5 ]

21 голосов
/ 24 марта 2010

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

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

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

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

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

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

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

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

5 голосов
/ 22 марта 2010

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

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

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

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

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

1 голос
/ 13 июня 2012

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

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

1 голос
/ 23 марта 2010

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

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

0 голосов
/ 22 марта 2010

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

Концепция передаваемого «сообщения» не сразу очевидна в WF.Тем не менее, понятие объектов, действующих как дискретные машины, выглядит следующим образом:

Для удивительной (но несколько сумасшедшей) книги о состоянии ОО см. Объектное мышление Дэвида Веста .И посмотрите здесь для обсуждения Алана Кея, что ОО значит для него.

...