私は、ユーザーが実行時にドメイン固有のオブジェクトから独自のビジネス ルールを構築し、それらのルールをデータベースに保持してアプリケーションで使用できるインターフェイスを作成しています。これらのいくつかは複雑な述語であり、他のものはかなり複雑に見える関係でドメイン オブジェクトの組み合わせを必要とします。これまで、GoF、eval によるダイナミクス、および CodeDom について調べてきました。誰が何を使用すべきかについて提案がありますか?
4 に答える
実際には、WF を使用せずに WF ルール エンジン API を使用してアプリケーションを開発することができます。http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/08/09/WF-Rules-Engine-without-Workflow.aspxこれにより、多くの作業を省くことができます。
ルールはどのくらいの頻度で変更されますか?独自のルールをビジネスで構築(およびバージョン管理)できるシステムを構築することは、プログラマーがルールを動的に更新できるシステムを構築するよりもはるかに困難です。
過去のプロジェクトで同様の要件が発生したとき、ビジネスはそうですが、ルールが変更されることを認めました。彼らはそれほど頻繁に変更されないので、更新を行うのは彼らでなければなりません。最終的に動的部分にIronPythonを使用し、コードをデータベースに保存すると、システムはロード時に適切なルールをプルアップします。アプリの残りの部分はC#で記述されています。私たちとビジネスにとっての勝利。
1 年かけてルール エンジンを構築し、アプローチに取り組みましたが、それは簡単なことではないと言えます。特に、自分の目標が何であるかに集中するとき。ユーザーにシステムのルールを書かせるのであれば、その領域に集中する必要があります。開発者にとって簡単なことは、おそらくほとんどのビジネス ユーザーにとってははるかに難しいことです。C# にコンパイルされ、動的に実行される Excel でルール オーサリング プラットフォームを構築しました...問題は、ユーザーがスプレッドシートとロジックの流れが複雑すぎることに気づき、ASp.NET 請負業者を雇ってルールを構築することでした。
BizTalk には、.NET アプリケーションに使用できると思われるエンジンがあります http://www.microsoft.com/biztalk/en/us/business-rule-framework.aspx
楽しむ!
カイゼン、ダイナミック ルールの範囲と種類に応じて、最終的に MS WF などのワークフロー エンジンを使用して、たとえばルールをワークフロー アクティビティとして定義できます。このようにして、ロジックを分離し、完全な再構築を必要としません。ワークフローで何かを変更する必要がある場合にアプリケーションを使用します。
これは最善の解決策ではないかもしれませんが、代替手段になる可能性があります...