12

私のプロジェクトでは、オブジェクトを取得して一連のルールに対して実行し、成功または失敗のいずれかを返し、失敗の理由のリストを返すビジネス オブジェクト検証レイヤーを作成する必要があります。これを達成するためのオプションがかなりあることを私は知っています。

マイクロソフトから:

オープンソース：

これらのテクノロジ (または私が挙げなかったもの) のいずれかで特に大きな成功または失敗を経験した人、またはビジネス ルールの検証に最も適していると思われるものについて意見を持っている人はいますか?

編集:一般的な検証文字列の長さが 200 未満、郵便番号が 5 桁または 5+4 であることについて質問しているだけではありませんが、ルール エンジンが実際に活用されると想定しています。

4

9 に答える 9

5

CSLA フレームワーク ルールの修正版。

他の多くのルール エンジンには、「エンド ユーザーはニーズに合わせてルールを変更できる」という約束があります。

ああ。ルール文書フォーマットの複雑さを学んだり、変更の複雑さと影響を理解できるユーザーはほとんどいません。

もう 1 つの約束は、コードを変更せずにルールを変更できることです。私はそう言う？「このフィールドを空白にすることはできません」という単純なルールであっても、ルールを変更すると、アプリケーションに非常に悪い影響を与える可能性があります。以前は空白にすることが許可されていたフィールドの場合、データ ストアに無効なデータが大量に存在することになります。さらに、最新のアプリケーションは、Web ベースであるか、click=once などのテクノロジーを介して配布/更新されています。そのため、ルール ファイルを更新するのと同じくらい簡単に、いくつかのコンポーネントを更新できます。

したがって、開発者はいずれにせよそれらを変更する予定であり、それらはビジネス オブジェクト操作の中核であるため、それらを 1 か所に配置し、最新の言語とフレームワークの機能を使用するだけです。

于 2009-02-14T05:04:57.433 に答える
3

私は、Microsoft が提供するルール ブロックと検証ブロックが (複雑すぎて柔軟性に欠ける) あまり好きではなかったため、カスタム ビジネス ワークフロー エンジンの経験に基づいて独自のブロックを作成する必要がありました。

数回の反復の後、プロジェクトは最終的にオープン ソース (BSD ライセンス) になり、実稼働システムで役立つことが証明されました。検証およびビジネス ルール用の .NET アプリケーション ブロックの主な機能:

  • 簡単に始められる
  • ドメイン オブジェクトのルール
  • ルールの再利用性
  • 事前定義された検証ルール
  • 動作の拡張性
  • 適切なオブジェクトのネスト
  • DDD および UI レベルの検証用に設計されています
  • 複数の報告レベル
  • 本番環境でのアクティブな開発
  • 小さなコードベース
  • オープンソース

UI レベルでのルールの単純なバインディングは次のようになります。

ルールを UI にバインドする

現在の実装には、現時点で DSL がないことに注意してください。C# 構文はそれ自体で十分に表現力があるため、Boo ベースの DSL を追加する必要はありません。

于 2009-02-08T08:52:35.087 に答える
2

私は、非常に単純な検証のために、自分自身の非常に小さくてコンパクトなルール エンジンを作成する傾向があることを認めなければなりません。これは主に、小さなプロジェクトでは他の誰かの実装を使用する価値がないと考えているためです。

于 2009-02-07T22:08:15.807 に答える
1

自分で作成することに興味がある場合は、ルール処理に関する JP Boodhoo の投稿をお読みください。基本的に、彼はドメイン オブジェクトを検証するための単純なフレームワークを展開しています。

ドメイン層での検証

ドメイン レイヤー 2 での検証

于 2009-02-15T18:00:12.403 に答える
1

試す

http://rulesengine.codeplex.com

軽量で、流暢なインターフェイスを使用して検証ロジックを定義し、拡張可能で、無料です! インターフェイスでルールを定義することもでき、実装者はルールを継承します。

迷惑な属性スタイルの検証はもう必要ありません - 検証したいクラスを所有していない場合

Asp.Net MVC (サーバー側のみ) へのプラグインがあります。

スクリーンショットに示すように、 RulesEngineを使用して自己検証 UI を提供する Polymod.Netという別のプロジェクトもあります。

于 2012-03-16T05:34:12.903 に答える
1

私は Workflow Foundation を試し、EntLib を使用し、独自のルール エンジンを作成しました。

無効なデータが DB に忍び込まないようにするために UI ベースの検証のみを行う必要がある小規模なアプリケーションでは、EntLib Validation Block を使用します。使い方は簡単で、ドメイン オブジェクトに最小限のコードしか必要としないだけでなく、NHibernate やその他のテクノロジ スタックを台無しにすることもありません。

複雑なもの、ドメイン層の検証などについては、簡単に独自のルール エンジンを再度作成することを選択します。私はむしろコードでルールを書きたいと思っています。各ルールは独自の小さなクラスであり、簡単にテストでき、ルールの複雑なセットを構成するのが非常に簡単です。

この種のルール エンジンを記述した大規模なアプリでは、FitNesse を使用してルール構成をテストしました。正確さを保証するために利用するそのようなツールを持っていることは素晴らしいことでした. テーブルとデータのテーブルをフィードして、構成したルールが機能していることを確実に知ることができます。

于 2009-02-12T05:12:37.010 に答える
0

CSLA Frameworkの使用をお勧めします。検証だけでなく、他の機能についても。

于 2009-02-12T05:22:34.897 に答える
0

Enterprise Library Validation Block provides a very AOP like approach and keeps things simple in both 3.1 and 4.1 from my experience.

于 2009-02-07T22:14:00.210 に答える