開発される大規模なアプリケーションについては、検証フレームワークを選択中です。ワークフロールールエンジンは厳密には検証フレームワークではありませんが、ワークフローファンデーションを使用せずに単独で使用できます。実行時に使用されるデータベースでルールを柔軟に指定できるようです。ただし、コードでルールを指定できないようです。
柔軟性の向上が要件の1つである場合（必ずしもビジネスアナリストがルールを編集する必要があるとは限りません）、2つのうちどちらを好みますか。その理由は何ですか。
1110 次
1 に答える
2
あなたの正確な要件が何であるかは非常に重要です。「柔軟であること」は、測定できないため、それ自体は適切な要件ではありません。何かが柔軟であるかどうかは非常に主観的です。
私はMicrosoftBusinessRules Engineに精通していないので、コメントすることはできません。ただし、私はMicrosoft Enterprise Library Validation Application Block（VAB）に精通しており、昨年は非常に役立ちました。それは私が扱っている状況に柔軟にするいくつかの機能を持っています：
- これにより、検証宣言の定義（属性を使用）と外部構成ファイルの使用（エンティティが生成されるときに非常に役立ちます）の両方が可能になります。
- これには、使用可能なデフォルトのバリデーターのセットが含まれており、カスタムのバリデーターを作成できます。
- これにより、単一のプロパティの検証が可能になり、複数のプロパティをグループとして比較できます（自己検証またはカスタムバリデーターを使用）。
- オブジェクトグラフだけでなく、オブジェクトを分離して検証することもできます。
- これにより、複数の「ルールセット」を定義できます。たとえば、一連のハードエラーと一連の警告を定義できます。
VAB（またはエンタープライズライブラリ全体）を使用すると、カスタム構成ソース（IConfigurationSource）を記述して、必要な場所でビジネスルールを定義できます。したがって、理論的にはそれらをデータベースに保存できますが、そのような構成ソースを自分で作成する必要があり、これはかなりの作業になります。特に、ビジネスアナリストが検証を定義し、ある種の編集ツールを使用してデータベースを更新できるようにしたい場合、VABを使用してこれを実現するのは非常に困難だと思います。
これらのルールを自分で作成するというビジネスマンの要件が本当にある場合は、この要件をサポートするプロセスを取得できれば幸いです。たとえば、変更が正しいかどうかをどのようにテストしますか？ビジネスアナリストが本番データベースに直接変更を加えることは望ましくありません。
しかし、これを考えてください。ルールをテストする場合は、それらのルールを本番データベースで直接変更しないことを期待します。そうしないと、事後にテストすることになります。したがって、アナリストは独自の環境でルールを変更し、おそらくこの環境からテスト環境に、そして後で受け入れ環境に、そして最終的には実稼働環境に新しいルールを公開することになります。また、これらの手順を実行している場合でも、データベースを使用してこれらのビジネスルールを保存する必要がありますか？構成ファイルを使用すると、データベースを使用するよりもはるかに簡単になります。デプロイメントは、複数のテーブルのコンテンツをデータベースからデータベースにコピーするのではなく、単にファイルのコピーになります。
私は、他の人がよく知っている検証フレームワークについて何を言わなければならないかに興味があります。
于 2010-02-16T15:28:18.253 に答える