Шаблон проектирования для моделирования потока выполнения работ

Question

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

Например, допустим, задание импортирует текстовый файл в базу данных. Предварительным условием было бы проверить, существует ли исходный файл, а последующим условием было бы проверить, существуют ли данные в базе данных.

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

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

Answer 1

Рассмотрите возможность интеграции вашего приложения с механизмом правил (также известным как бизнес-правила).Идея в том, что логика определяется вне кода и хранится в таблице или файле.Механизм правил читает правило и интерпретирует.

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

Хорошее вступление Мартина Фаулера: http://martinfowler.com/bliki/RulesEngine.html

Статья с чуть более содержательным содержанием: http://www.infoq.com/articles/Rule-Engines

Чтобы найти актуальный код, введите «движок правил» или «движок рабочего процесса» в Google и добавьте имя вашего языка программирования («Java», «C #» или что-то еще).

Answer 2

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

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

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

Я создал новую систему с метаданными, управляемыми таблицами, которые указывали на непосредственные зависимости между таблицами. Другими словами, таблица A имеет FK для таблиц B и C. Вместо того, чтобы вручную отслеживать все взаимозависимостей вручную, отслеживались только непосредственные взаимозависимости. Тогда планировщику просто нужно было посмотреть, какие нагрузки завершены, а какие - нет. Любая ожидающая загрузка, у которой не было неполных зависимостей, могла начинаться нормально.

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