Лучше иметь один большой рабочий процесс или несколько меньших конкретных?

Question

Мне нужно создать приложение, которое получает файлы с сервера и перемещается на другой сервер. Было предложено изучить использование Windows Workflow Foundation (WF).

Я начал строить рабочий процесс, но он становится грязным, и я не уверен, что делаю это наилучшим образом.

Вот основные рабочие занятия:

Получить список источников Определите, является ли источник ftp или дисковод Получить список файлов с сервера Если источником является ftp, тогда получите файл с помощью ftp, иначе, если источником является диск, тогда читайте файл с диска Если целью является ftp, тогда ftp файл отправляется на сервер, если целью является диск, тогда пишите на диск, если целью является веб-служба, затем отправьте сообщение в веб-службу. Если источником является ftp, удалите файл с помощью команд ftp, в противном случае удалите файл

С одним рабочим процессом он становится немного занятым. Мне нужно 2 цикла while, один вокруг интеграций и один после того, как я получу список файлов.

Другая вещь, о которой я подумал, заключалась в создании нескольких рабочих процессов. Один для FTPtoFTP, FTPtoDrive, FTPtoWebServie, DriveToFTP, DrivetoDrive, DriveToWebService.

Есть предложения?

Answer 1

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

В вашем примере бизнес-правила в значительной степени похожи на вещи, которые должны обрабатываться файлом app.config.

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

Например WF для построения стола

• покупка древесины
• резаная древесина
• резаная древесина для ног
• кромки скоса
• круглые карнизы
• песок дважды с разной крупностью
• сборочный стол

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

Таким образом, шагу рабочего процесса GetDatasource не будет важно (внешне), из какого типа источника данных он собирается, он просто возвращает к следующему шагу в рабочем процессе набор данных.

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

Таким образом, ваш рабочий процесс может быть тремя рабочими процессами

Максимальный WF

1. GetDataSourceWF
2. DoThingsWithDataWF

Тогда ваши рабочие процессы DoThingsWithDataWF и GetDataSourceWF могут быть связаны только с тем контекстом выполнения, который им необходим.

EDIT

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

Answer 2

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

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

Разделение его на несколько рабочих процессов может не самый лучший подход, если вы не можете разбить его на несколько высокоуровневых действий и работать на уровне XAML. Имейте в виду, что если логика и последовательность действий практически идентичны для всех из них, теперь вам нужно будет поддерживать 6 различных рабочих процессов. Это больший кошмар, если ваши рабочие процессы сложны, и вам нужно исправить общую логическую ошибку во всех из них.

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

Answer 3

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

Answer 4

Ну, лично я еще не использовал WWF. Я сделал довольно много рабочих процессов раньше, хотя. Мне кажется, лучший способ - разбить их на более мелкие рабочие процессы. Когда вы работаете с рабочими процессами, вы должны попытаться ограничить каждый рабочий процесс определенной задачей, чтобы у вас было определенное начальное действие и по крайней мере один успешный маршрут и по крайней мере один маршрут отказа. Рабочие процессы в целом могут быть очень хитрыми, и каждый из них должен быть максимально простым.