Динамические Бизнес-правила в веб-приложении
Посмотрите на настройки конфигурации прокси ... попробуйте снять галочку с его использования
6 ответов
Я реализовал большинство упомянутых вами подходов. Ответ может зависеть от множества факторов.
Какая роль (роли) клиента будет вносить изменения в бизнес-правила (например, бизнес-аналитик, разработчик, опытный пользователь и т. Д.)? Для полноценной поддержки бизнес-аналитиков может потребоваться механизм правил с внешними правилами в базе данных и удобным пользовательским интерфейсом. Значимая поддержка для разработчиков может быть такой же простой, как использование чего-то вроде MEF ( http://www.codeplex.com/MEF ).
Вы также можете учесть, как часто нужно будет учитывать бизнес-правила. изменились и какие типы связанных операционных требований могут применяться (например, хост-процесс должен оставаться запущенным, выгрузка домена приложения завершена и т. д.) Хороший выбор может потребовать тщательного обдумывания вероятных и маловероятных будущих потребностей.
Вы можете создавать бизнес-правила, управляемые данными, например это . Деревья решений также могут быть хорошим вариантом.
Вы также можете подумать об аспектно-ориентированном программировании как о способе реализации бизнес-правил.
Мое единственное предостережение относительно механизма правил индукции Rete состоит в том, что наборы правил должны держите их маленькими и близко к объектам, которые их используют. Если вы можете инкапсулировать поведение объекта в механизме правил, который является частью его состояния, тем лучше. Меня не интересует "корпоративное" решение, которое сбрасывает тысячи правил в одноэлементный механизм правил, который становится зависимостью для каждой части предприятия.
Возможно, это не лучший подход, но моя компания успешно реализовала ваш вариант №2 в нескольких случаях.
В основном мы настраиваем клиентов в базе данных или файле конфигурации, а также для для каждого клиента должна существовать таблица поиска, в которой хранится имя класса, вызываемое для выполнения любой бизнес-операции. Когда код получает запрос для клиента A, он ищет класс для использования, создает его и выполняет через отражение.
Я не большой поклонник помещения вещей, связанных с кодом, в базу данных, но на самом деле это работает нормально и в данном случае не слишком сложно.
Я создал динамический механизм правил, основанный на следующем механизме бизнес-правил .NET с открытым исходным кодом NxBRE . Я использовал механизм потока в качестве основного примера для своего механизма динамических правил.
Я использовал ту же архитектуру, что упоминается в вашем вопросе.
Мне нравится WF, но если вы посмотрели на него и решили, что хотите чего-то другого, вам следует взглянуть на K2 . Кроме того, BizTalk поддерживает BRE.
Я предлагаю комбинацию 1 и 3.
Но не делайте этого. сохранить рабочий процесс в базе данных, сохранить это дерево решений или поток правил (как мы их называем).
Изменение рабочего процесса, чтобы приспособить его к конкретному клиенту или интегрировать его в их профиль, является простой задачей, если у вас есть визуальный инструмент, управляемый действиями, такой как Визуальные правила . Также есть много преимуществ, если ваш бизнес-аналитик или сотрудник службы поддержки внесут это изменение без необходимости корректировать код.
Также ни одно из этих требований не требует сложных инструментов ИИ, таких как RETE и логический вывод - лучше всего использовать последовательную логику. .