답변:
Java 규칙 엔진 JESS 및 Drools를 채택하는 데 대한 장단점은 무엇입니까?
애플리케이션 로직에서 비즈니스 규칙을 분리해야하는 경우 규칙 엔진을 사용하십시오. 는 프로젝트가 필요 규칙 엔진합니까 문서는 좋은 예제가 실려있다 :
예를 들어, 일반적인 상점 첫 화면 시스템에는 할인을 계산하는 코드가 포함될 수 있습니다.
if (product.quantity > 100 && product.quantity < 500) { product.discount = 2; } else if (product.quantity >= 500 && product.quantity < 2000) { product.discount = 5; } else if (product.quantity >= 2000) { product.discount = 10; }규칙 엔진은 위의 코드를 다음과 같은 코드로 대체합니다.
ruleEngine.applyRules(product);
비전문가의 손에 규칙 관리 콘솔을 제공하는 것이 좋은지 여부를 결정하는 것은 귀하에게 달려 있습니다. :)
규칙 엔진을 사용해야합니까?의 자세한 내용은 ? , 규칙 엔진을 사용하는 이유는 무엇입니까? , 규칙 엔진 및 Google 사용 여부를 결정하기위한 몇 가지 지침 .
다른 선수가 있습니까?
다른 플레이어로는 JRules, Corticon이 있습니다 (JRules는 가장 유명한 IMO-최고를 의미하지는 않습니다).
사용 용이성, 성능, 코드와의 통합 수준과 같은 다른 영역에서 어떻게 비교합니까?
정확하게 말할 수는 없지만 Drools에 대해 약간의 (긍정적 인) 경험이 있습니다. 그러나 JBoss Drools vs ILog JRules-일화 이야기 (반드시 읽어보십시오) 또는 JRules 관점에서 Drools 작업과 같은 블로그 게시물에서 피드백을 얻을 수 있습니다 . Google에서 더 많이 찾을 수있을 것이라고 확신합니다 (하지만 Drools를 사용해 보겠습니다).
이제 애플리케이션 서버에서 사용할 규칙을 평가하고 있습니다. 우리는 OpenRules 를 만났습니다. Java와 통합하기 쉽고 테스트에서 보여준 한 충분히 빠른 를 발견했습니다. 다른 것보다 OpenRules의 가장 큰 장점은 규칙이 수정되고 처리되는 방식입니다. 모든 것이 프로그래머가 아닌 사람에게 가장 쉬운 방법 인 Excel 표에서 발생합니다. 관련된 모든 사람들, 심지어 비전문가들도 모든 것을 완벽하게 이해했습니다. :-)
우리는 또한 침 흘림을 통합했지만 더 프로그래밍 방식의 접근 방식이므로 규칙을 이해하기가 훨씬 더 복잡합니다. 이것이 바로 우리가 OpenRules를 고수하는 이유입니다.
많은 사람들이 응용 프로그램의 특정 기능을 활성화하거나 비활성화하기 위해 특정 조건이 충족되는지 여부를 관리하는 것과 유사한 것을 찾고 있다는 사실을 추가하면됩니다.
나는 어디를 가든 동일한 패턴을 다시 구현하는 데 지쳐서 Roolie http://sourceforge.net/projects/roolie/ 라는 OSS 프로젝트를 만들기로 결정했습니다 .
나는 방금 그것을 maven-ized했고 그것이 출시 된 2010 년 이후보고 된 버그가 없었기 때문에 Maven Central에서 호스팅하는 데 필요한 것 외에는 변경하지 않고 v 1.0으로 업그레이드했습니다. ).
기본적으로 JSR-94는 대부분의 경우 과잉이며, 현재 제공하는 것과 함께 진행되는 학습 곡선과 오버 헤드가 엄청납니다. 그것이 당신이 원하는 것이라면 괜찮습니다. 그러나 상태 테스트를 유지하기 위해 Java로 작성된 간단한 규칙을 XML과 함께 연결하려는 경우 Roolie는이를 수행하는 매우 빠른 방법입니다. 의존성과 학습 곡선이 없습니다.
규칙 엔진이 필요했을 때 우리는 사용 가능한 것이 우리의 간단한 작업에 너무 복잡했기 때문에 우리 자신의 엔진을 사용하기로 결정했습니다. 사용자가 입력 할 수있는 구문 분석 식에 대해 원격으로 경험 한 경우에도 그렇게하기가 그리 어렵지 않습니다. 우리의 경우 대부분의 사양은 XSD에 의해 처리되며 일부 필드 만 추가로 구문 분석됩니다.