Бизнес-правила, управляемые базой данных Java - мысли о дизайне? - PullRequest
0 голосов
/ 06 апреля 2011

Мое корпоративное приложение в настоящее время работает на Weblogic 10.3.4, Java 1.6 и Spring 2.0.8. Это недавнее обновление, поэтому Spring еще не обновлен, а часть базы Java-кода все еще в старом стиле 1.4.

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

С каждым запросом формы будет связано любое количество правил, которые будут настроены с использованием нескольких базовых таблиц базы данных.

На данный момент мой дизайн таков, что каждое правило, определенное в базе данных, будет отображаться через Spring в компонент Singleton Stateless Spring. С учетом состояния формы каждое правило будет возвращать Respose Respose объект. Смотрите фрагмент кода ниже:

 //get List of rules for form from database
 List<RuleConfiguration>  rules = RulesService.getRulesForFormRuleset(formType, filingMethod, rsName, document);

    IssueDocument issues = new IssueDocumentImpl();

     for (RuleConfiguration ruleConfig : rules) {


         //create a rule instance from the Spring Bean Factory
         Rule rule = (Rule) beanFactory.getBean(ruleConfig.getRule().getRuleBeanName());
         RulesIssue issue = rule.runRule(document, ruleConfig);

            if (issue != null)  {  //Issue has been populated rule must have fired
                issues.addNewIssue(issue);
            }
     }

    return issues;

Похоже ли это на разумное решение? Я стремился внедрить «легкое прикосновение», решение которого было полностью исключено из EJB, поскольку существует более 500 правил, которые в конечном итоге должны быть написаны. Моя главная проблема заключается в том, что, поскольку все они являются синглетонами, и на мой «механизм правил» будет большой спрос, нужно ли мне рассматривать какое-либо объединение бинов? Любые другие отзывы будут приветствоваться. Разорви меня в клочья, если хочешь - я могу взять это!

Большое спасибо

1 Ответ

0 голосов
/ 06 апреля 2011

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

Первый - определить правила, а второй - фактически выполнить их.

В зависимости от вашей фильтрации и динамичности, запросы правил могут быть легко запомнены, поэтому, вероятно, стоимость поиска приблизится к нулю.500 правил - это не много, если подумать.

Далее - фактическое исполнение.Если все ваши вещи являются синглетонами, то вам нужно позаботиться о запуске синглтонов, безопасности потоков и т. Д.

По сути, просто убедитесь, что каждое из ваших правил имеет жизненный цикл.«запустить» «запустить» «остановить».Если это настоящий синглтон, которому требуется некоторое состояние от запуска к запуску, то методы start и stop, скорее всего, будут содержать логику.Если для входов требуется лишь небольшая логика, то, вероятно, нет необходимости запускать и останавливать (они могут быть пустыми методами), или чтобы он вообще был одиночным, так что просто создайте новый экземпляр, запустите егои выбросьте его.

Вы не упоминаете, что такое "правило" с точки зрения логики.Это могут быть простые Java-классы, которые следуют этому жизненному циклу.Добавьте аннотацию @SingeletonRule или внедрите isSingleton, что угодно.

Действительно, на этом уровне в этой системе мало ракетостроения.Магия в основном заключается в метаданных и фактическом создании списка правил для исполнения.

Простые системы правил просты.

...