私はあなたがやりたいことに似た何かをしている最中です。
これらのビジネスルールはビジネスによって頻繁に発生するため、GUIを使用してルールに必要な変更を加えてほしいと思います。
警告警告警告!!! GUIがある限り、プログラマー以外の人がそれを使用できるというのはよくある誤解です。それは...私が到達した結論ではありません。それは役に立ちますが、プログラミングの難しい部分はコードを書くことではなく、正しい問題に対する良い解決策を考え出すことです。より知的で技術的に傾倒しているビジネスマンの何人かはGuvnorで何かをすることができると確信していますが、それが魔法の至福の地へのある種の黄色いレンガの道であるとは期待しないでください。それでも、ビジネスマンに必要なことを実行できるが、やりたくないことを誤って実行することを防ぐ、健全なデータモデルとAPIを提供する必要があります。
1. Droolsは、ルールを編集するための軽量GUIをサポートしていますか?
2. Drools Guvnorは軽量のGUIですか、それともそれを下げる方法はありますか?
さて、「軽量」については議論の余地がありますが、Guvnorはかなりうまく機能し、ブラウザ以上のものを必要としないので、大丈夫だと思います。
3.ルールを読むためにアプリケーションをGuvnorに統合するのはどれくらい簡単ですか?
Guvnorを起動して実行したら、を使用KnowledgeAgent
してGuvnorに接続し、新しいルールの更新をリッスンするようにアプリケーションを接続することは、特に難しいことではありません。
残念ながら、一般的にDrools、特にGuvnorには、回避しなければならない可能性のある多くの癖があります(たとえば、Guvnor WARファイルを分解し、WEB-INF/beans.xml内のファイルを編集して非デフォルト設定...)。しかし、それをまっすぐにしたら、それはかなりうまくいくと思います。
ドキュメントに関しては、Javadocは時々少しまばらになることがありますが、Webサイトにはかなり良いものがいくつかあり、いくつかの本が含まれています。
全体として、DroolsとGuvnorは強力なツールですが、それらを機能させるのは簡単ではありません。彼らが提供しなければならないものが本当に必要な場合、彼らはそれだけの価値がありますが、より単純なスクリプトソリューションで十分かどうかを検討する価値があるかもしれません。
さて、あなたが実際にDroolsを必要としていることに気付いた場合、ここに私の一番のアドバイスがあります-データベースとルールのために別々のデータモデルを保持してください。書くべき退屈な変換コードがたくさんあることを意味しますが、それだけの価値はあります。
私が取り組んでいるアプリはデータベースの問題にJPAを使用しており、そのデータモデルをルールで使用するのはあまり快適ではありませんでした。いくつかの理由:
データレイヤーに適合するものが必ずしもDroolsに適合するとは限りません。その逆も同様です。
ツリー構造があります。これは、JPAでは当然@OneToMany
、親ノードのリスト内の子との関係です。Droolsでリストを操作するのはかなり面倒だったので、1つParentNode
のオブジェクトと多数のオブジェクトを挿入する構造にフラット化しましたChildNode
。これは、操作がはるかに簡単でした。
あえてリファクタリングします。
ルールのデータモデルもGuvnor内に存在する必要があります。つまり、エンティティクラスなどの名前を変更すると、すべてのルールが破られる可能性があります。ルール用の個別のデータモデルは、データベースのものを心配することなくリファクタリングできることを意味します。
彼らが見る必要があるものを彼らに見せてください。
データベースはかなり複雑になる可能性がありますが、通常、ルールはこれらの複雑さの多くを気にする必要はありません。これらの複雑さを編集ルールの人々に公開すると、多くの不必要な混乱を引き起こす可能性があります。たとえば、私たちのシナリオでは、ルール作成者を多対多の関係(Droolsで処理するのは非常に複雑であることが判明)にさらす必要がまったくないことがわかりました。そのため、代わりに1対多のように見せます。 、そしてすべてがより自然になります。
保護。
ほとんどのルールは、次の擬似コードのように機能するように設計されています。
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
...したがって、ルールパッケージごとに、挿入できる応答コマンドとその機能が明確に定義されています。アプリでルールを実行した後、ルールによってセッションに挿入されたオブジェクトを選択し、それらに基づいて行動します(ビジターパターンは、長いif instanceof
//チェーンを回避するのに非常に役立つことが証明されています)。else if instanceof
else
ルール作成者にJPAオブジェクトでやりたいと思うことを何でもさせるのではなく、この方法でそれを行ったことを非常に嬉しく思います。
とにかく、これが役立つことを願っています。