ข้อดีและข้อเสียของเอ็นจินกฎ Java [ปิด]

อะไรคือข้อดีและข้อเสียเพื่อการนำ Java กฎเครื่องมือJESSและDrools ? มีผู้เล่นคนอื่นหรือไม่?

ฉันเข้าใจว่า Drools เป็น Open Source และ JESS ไม่ใช่ แต่จะเปรียบเทียบในด้านอื่น ๆ เช่นความสะดวกในการใช้งานประสิทธิภาพระดับการผสานรวมกับโค้ดของคุณได้อย่างไร

อะไรคือข้อดีและข้อเสียในการใช้เครื่องมือกฎ Java JESS และ Drools

ใช้เอ็นจินกฎหากคุณต้องการแยกกฎทางธุรกิจออกจากตรรกะของแอปพลิเคชัน บทความของคุณต้องการ Rule Engineมีตัวอย่างที่ดี:

ตัวอย่างเช่นระบบขายหน้าร้านทั่วไปอาจใช้รหัสเพื่อคำนวณส่วนลด:

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);

ขึ้นอยู่กับคุณที่จะตัดสินใจว่าการวางคอนโซลผู้ดูแลระบบไว้ในมือของผู้ที่ไม่ได้ใช้เทคนิคเป็นสิ่งที่ดีหรือไม่ :)

รายละเอียดเพิ่มเติมในฉันควรใช้ Rules Engine หรือไม่ , ใช้โปรแกรมกฎทำไม? , บางแนวทางสำหรับการตัดสินใจว่าจะใช้กฎเครื่องยนต์และGoogle

มีผู้เล่นคนอื่นหรือไม่?

ผู้เล่นคนอื่น ๆ ได้แก่ JRules, Corticon (JRules เป็น IMO ที่มีชื่อเสียงที่สุด - ซึ่งไม่ได้หมายความว่าดีที่สุด)

พวกเขาเปรียบเทียบในด้านอื่น ๆ เช่นความสะดวกในการใช้งานประสิทธิภาพระดับการผสานรวมกับโค้ดของคุณอย่างไร

ไม่สามารถบอกคุณได้อย่างแม่นยำฉันมีประสบการณ์เพียงเล็กน้อย (เชิงบวก) กับ Drools แต่คุณจะได้รับข้อเสนอแนะจากการโพสต์บล็อกเช่นJBoss Drools VS ILOG JRules - เรื่องราวประวัติ (โปรดอ่าน) หรือการทำงานกับ Drools จากมุมมอง ฉันแน่ใจว่าคุณสามารถค้นหาสิ่งเหล่านี้ได้มากขึ้นใน Google (แต่ฉันจะลอง Drools)

ขณะนี้เรากำลังประเมินกฎสำหรับใช้กับแอปพลิเคชันเซิร์ฟเวอร์ของเรา เราได้พบกับOpenRulesซึ่งง่ายต่อการรวมเข้ากับ Java และเท่าที่การทดสอบของเราแสดงให้เห็นว่าเร็วพอ ข้อได้เปรียบหลักของ OpenRules เหนือข้ออื่น ๆ คือวิธีการแก้ไขและจัดการกฎ ทุกอย่างเกิดขึ้นในตาราง Excel ซึ่งเป็นวิธีที่ง่ายที่สุดสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์ ทุกคนที่เกี่ยวข้องแม้กระทั่งคนที่ไม่ใช่สายเทคนิคก็เข้าใจทุกอย่างอย่างถ่องแท้ :-)

นอกจากนี้เรายังมีการรวม drools ไว้ด้วย แต่กฎมีความซับซ้อนมากขึ้นในการทำความเข้าใจเนื่องจากเป็นวิธีการแบบเป็นโปรแกรมมากกว่า นั่นเป็นเหตุผลที่เรามักจะยึดติดกับ OpenRules

เรามีคำถามคล้าย ๆ กันกับเราในที่สุดเราก็หยิบ Drools ขึ้นมาหนึ่งควรใช้ drools หากคุณมีดังต่อไปนี้:

• ตรรกะทางธุรกิจที่คุณคิดว่ายุ่งเหยิงด้วย if หลายเงื่อนไขเนื่องจากสถานการณ์ที่หลากหลาย
• คุณจะมีความต้องการเพิ่มขึ้นจากความซับซ้อนที่เพิ่มขึ้น
• การเปลี่ยนแปลงตรรกะทางธุรกิจจะเกิดขึ้นบ่อยครั้ง (1-2 ครั้งต่อปีก็จะเกิดขึ้นบ่อยๆ)
• เซิร์ฟเวอร์ของคุณมีหน่วยความจำเพียงพอเนื่องจากเป็นเครื่องมือที่ใช้หน่วยความจำจึงให้ประสิทธิภาพในราคาหน่วยความจำ

มีรายละเอียดเพิ่มเติมที่URLต่อไปนี้

เพียงเพิ่มว่าหลาย ๆ คนกำลังมองหาสิ่งที่คล้ายกับการจัดการว่าตรงตามเงื่อนไขบางประการเพื่อเปิดหรือปิดใช้งานคุณสมบัติบางอย่างในแอปพลิเคชัน

ฉันเริ่มเบื่อกับการนำรูปแบบเดิม ๆ กลับมาใช้ซ้ำแล้วซ้ำอีกในทุกที่ที่ฉันไปดังนั้นฉันจึงตัดสินใจสร้างโครงการ OSS ที่เรียกว่า Roolie http://sourceforge.net/projects/roolie/

ฉันเพิ่ง maven-ized และเนื่องจากไม่มีรายงานข้อบกพร่องตั้งแต่ปี 2010 เมื่อเปิดตัวฉันจึงอัปเกรดเป็น v 1.0 โดยไม่มีการเปลี่ยนแปลงใด ๆ นอกเหนือจากที่ต้องโฮสต์ที่ Maven Central (ซึ่งฉันกำลังดำเนินการ ).

โดยทั่วไป JSR-94 นั้นใช้งานมากเกินไปสำหรับทุกสิ่งและมีช่วงการเรียนรู้ขนาดใหญ่และค่าใช้จ่ายที่สอดคล้องกับข้อเสนอปัจจุบัน ไม่เป็นไรถ้านั่นคือสิ่งที่คุณต้องการ แต่ถ้าคุณต้องการเชื่อมโยงกฎง่ายๆที่เขียนใน Java ร่วมกับ XML เพื่อรักษาการทดสอบสถานะของคุณ Roolie เป็นวิธีที่รวดเร็วมาก ไม่มีการพึ่งพาและไม่มีเส้นโค้งการเรียนรู้

เมื่อเราต้องการกลไกกฎเราจึงตัดสินใจที่จะม้วนของเราเองเพราะสิ่งที่มีอยู่นั้นซับซ้อนเกินไปสำหรับงานง่ายๆของเรา หากคุณมีประสบการณ์จากระยะไกลกับนิพจน์การแยกวิเคราะห์ที่ผู้ใช้อาจใส่ไว้ก็ไม่ยากที่จะทำ ในกรณีของเราข้อมูลจำเพาะส่วนใหญ่ได้รับการจัดการโดย XSD และมีเพียงไม่กี่ฟิลด์เท่านั้นที่จะแยกวิเคราะห์เพิ่มเติม