Динамические бизнес-правила в веб-приложении

Question

Привет!

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

1. Рабочий процесс Windows: создание динамических рабочих процессов и сохранение их в базе данных.
2. Отражение: создание интерфейса бизнес-правил и использование отражения для загрузки пользовательской сборки клиента.
3. Настоящий двигатель бизнес-правил
4. Реализация IOC Контейнер, как карта структуры. [zaff: добавлено 6/4]

Вы когда-нибудь реализовывали что-нибудь подобное? Если да, каков ваш опыт? И, наконец, есть ли другое решение, которое я должен изучить?

Спасибо за вашу помощь !!

Answer 1

Я реализовал большинство упомянутых вами подходов. Ответ может зависеть от множества факторов.

Какая роль (и) клиента будет вносить изменения в бизнес-правила (например, бизнес-аналитик, разработчик, опытный пользователь и т. Д.)? Для полноценной поддержки бизнес-аналитиков может потребоваться механизм правил с внешними правилами в БД и удобным пользовательским интерфейсом. Значительная поддержка разработчиков может быть такой же простой, как использование чего-то вроде MEF (http://www.codeplex.com/MEF).

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

Answer 2

Вы можете выполнять бизнес-правила, основанные на данных, например this . Деревья решений могут быть хорошим способом пойти.

Вы также можете думать о аспектно-ориентированном программировании как о способе реализации бизнес-правил.

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

Answer 3

Я предлагаю комбинацию 1 и 3.

Но не храните рабочий процесс в базе данных, храните его как дерево решений или поток правил (как мы их называем).

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

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

Answer 4

Возможно, это не лучший подход, но моя компания успешно реализовала ваш вариант №2 в некоторых случаях.

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

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

Answer 5

Я создал динамическое ядро ​​правил на основе следующего открытого .NET Business Rule Engine NxBRE . Я использовал движок Flow в качестве основного примера для моего движка динамических правил.

Я использовал ту же архитектуру, что и в вашем вопросе.

Answer 6

Мне нравится WF, но если вы посмотрели на него и решили, что хотите что-то другое, вам стоит взглянуть на K2 . Кроме того, BizTalk имеет поддержку BRE.