Вопрос

Привет!

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

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

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

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top