Динамические бизнес-правила в веб-приложении
-
09-09-2019 - |
Вопрос
Привет!
При работе над веб-проектом клиент должен был настроить бизнес-правила и логику.Я хочу сделать это без необходимости перекомпилировать приложение каждый раз, когда мы регистрируем в системе новый клиент.Архитектуры, которые я обрисовал до сих пор:
- Рабочий процесс Windows:Создание динамических рабочих процессов и сохранение их в базе данных.
- Отражение:Создание интерфейса бизнес-правил и использование отражения для загрузки пользовательской клиентской сборки.
- Настоящий механизм бизнес-правил
- Реализация карты структуры, подобной контейнеру IOC.[зафф:добавлено 6/4]
Вы когда-нибудь реализовывали что-нибудь подобное?Если да, то каков ваш опыт?И, наконец, есть ли еще одно решение, которое мне следует изучить?
Спасибо за вашу помощь!!
Решение
Я реализовал большинство подходов, которые вы упомянули.Ответ может зависеть от множества факторов.
Какие роли клиента будут вносить изменения в бизнес-правила (например,бизнес-аналитик, разработчик, опытный пользователь и т. д.)?Для значимой поддержки бизнес-аналитиков может потребоваться механизм правил с внешними правилами в базе данных и удобный пользовательский интерфейс.Значимая поддержка для разработчиков может быть такой же простой, как использование чего-то вроде MEF (http://www.codeplex.com/MEF).
Вы также можете учитывать, как часто необходимо будет менять бизнес-правила и какие виды связанных с ними эксплуатационных требований могут применяться (например,хост-процесс должен продолжать работать, выгрузка домена приложения в порядке и т. д.).Хороший выбор может потребовать тщательного анализа вероятности и вероятности.маловероятные будущие потребности.
Другие советы
Вы можете создавать бизнес-правила, управляемые данными, например этот.Деревья решений также могут быть хорошим способом.
Вы также можете подумать об аспектно-ориентированном программировании как о способе реализации бизнес-правил.
Мое единственное предостережение относительно механизма правил индукции Rete заключается в том, что наборы правил должны быть небольшими и располагаться близко к объектам, которые их используют.Если вы можете инкапсулировать поведение объекта в обработчике правил, который является частью его состояния, тем лучше.Меня не волнует «корпоративное» решение, которое сбрасывает тысячи правил в единый механизм правил, который становится зависимостью для каждой части предприятия.
Возможно, это не лучший подход, но моя компания в нескольких случаях успешно реализовала ваш вариант №2.
По сути, мы настраиваем клиентов в базе данных или файле конфигурации, и для каждого клиента будет существовать таблица поиска, в которой хранится имя класса, который можно вызвать для выполнения любой бизнес-операции.Когда код получает запрос для клиента А, он ищет используемый класс, создает его и выполняет посредством отражения.
Я не большой поклонник помещения вещей, связанных с кодом, в базу данных, но на самом деле это работает нормально и в данном случае не слишком сложно.
Я предлагаю комбинацию 1 и 3.
Но не храните рабочий процесс в базе данных, храните его в виде дерева решений или потока правил (как мы их называем).
Изменение рабочего процесса для соответствия конкретному клиенту или объединение его с его профилем — простая задача, если у вас есть визуальный, управляемый действиями инструмент, такой как Визуальные правила.Также есть много преимуществ, если ваш бизнес-аналитик или специалист службы поддержки внесет эти изменения без необходимости корректировки кода.
Кроме того, ни одно из этих требований не требует использования сложных инструментов искусственного интеллекта, таких как RETE и логический вывод. Лучше всего подходит последовательная логика.
Я создал механизм динамических правил на основе следующего механизма бизнес-правил .NET с открытым исходным кодом. NxBRE.Я использовал движок Flow в качестве основного примера своего движка динамических правил.
Я использовал ту же архитектуру, упомянутую в вашем вопросе.