java - motor de reglas c#
Pros y contras de los motores de reglas de Java (5)
¿Cuáles son los pros y los contras de adoptar los motores de reglas de Java JESS y Drools?
Use un motor de reglas si necesita separar las reglas comerciales de la lógica de la aplicación. El artículo Does Does Project Need a Rule Engine tiene un buen ejemplo:
Por ejemplo, un sistema de escaparate típico podría incluir código para calcular un descuento:
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; }
Un motor de reglas reemplaza lo anterior con un código que se ve así:
ruleEngine.applyRules(product);
Depende de usted decidir si poner una consola de administración de reglas en manos de personas no técnicas es algo bueno o no :)
Más detalles en ¿Debo usar un motor de reglas? , ¿Por qué usar un motor de reglas? , Algunas pautas para decidir si usar un motor de reglas y en Google .
¿Hay otros jugadores?
Otros jugadores incluyen JRules, Corticon (JRules es el IMO más famoso, lo que no significa lo mejor).
¿Cómo se comparan en otras áreas, como la facilidad de uso, el rendimiento y el nivel de integración con su código?
No puedo decirlo con precisión, solo tengo una pequeña experiencia (positiva) con Drools. Pero obtendrás algunos comentarios de entradas de blog como JBoss Drools vs ILog JRules - una historia anecdótica (asegúrate de leerla) o Trabajando con Drools desde la perspectiva de JRules . Estoy seguro de que puedes encontrar más de ellos en Google (pero le daría una oportunidad a Drools).
Cuando necesitábamos un motor de reglas, decidimos lanzar el nuestro, porque los disponibles eran demasiado complicados para nuestras tareas simples. Si tiene experiencia remota con expresiones de análisis que los usuarios pueden agregar, esto no es muy difícil de hacer. En nuestro caso, la mayoría de las especificaciones son manejadas por un XSD y solo algunos de los campos se analizan aún más.
Estamos evaluando reglas para su uso con nuestro servidor de aplicaciones. Nos hemos topado con OpenRules , que es fácil de integrar con Java y, en la medida en que nuestras pruebas lo han demostrado, lo suficientemente rápido. La principal ventaja de OpenRules sobre los demás es la forma en que se modifican y manejan las reglas. Todo sucede en las tablas de Excel, que es la forma más fácil para los no programadores. Todos los involucrados, incluso las personas no técnicas, entendieron todo perfectamente :-)
También tenemos baquetas integradas, pero las reglas son mucho más complicadas de comprender ya que se trata de un enfoque más programático. Es por eso que, muy probablemente, nos apegaremos a OpenRules.
Solo agregué que muchas personas están buscando algo más parecido a la administración de si se cumplen ciertas condiciones para habilitar o deshabilitar ciertas características en una aplicación.
Me cansé de volver a implementar el mismo patrón una y otra vez donde sea que fuera, así que decidí hacer un proyecto de OSS llamado Roolie http://sourceforge.net/projects/roolie/
Lo diagnostiqué y, como no se han notificado errores desde 2010, cuando lo lanzaron, lo actualicé a v 1.0 sin más cambios que los necesarios para alojarlo en Maven Central (que estoy en proceso de hacer). )
Básicamente JSR-94 es excesivo para la mayoría de las cosas, y hay una gran curva de aprendizaje y gastos generales que van junto con las ofertas actuales. Eso está bien si eso es lo que quieres. Pero si solo quiere encadenar reglas simples escritas en Java junto con XML para mantener sus pruebas estatales, Roolie es una forma muy rápida de hacerlo. Sin dependencias y sin curva de aprendizaje.
Tuvimos una pregunta similar con nosotros, finalmente recogimos Drools, uno debería usar drools si tiene lo siguiente:
- La lógica empresarial que crees que se está abarrotando con múltiples condiciones si debido a la variedad de escenarios
- Tendrá una creciente demanda de aumento en la complejidad
- Los cambios en la lógica comercial serían frecuentes (1 a 2 veces al año también sería frecuente)
- Su servidor tiene suficiente memoria ya que es una herramienta que consume mucha memoria, brinda rendimiento a un costo de memoria
Tener más detalles en la siguiente URL