1

私は、ルールが常に強制可能であるとは限らないビジネスルールを処理するための最良の一般的な方法を見つけようとしています。
フォームは、stored_procedure呼び出しを介してデータベースに送信されています。現在、ビジネスロジックは、個別のビジネスアプリケーション層ではなく、stored_procedureに書き込まれています。ストアドプロシージャは、エラーとエラーレベル（情報、アドバイス、警告、エラー、および致命的）を含むデータセットを返します。

情報は、必要となる可能性のあるものに関する最新情報を提供するためのものです。
アドバイスにより、ユーザーは更新/挿入を中止できますが、デフォルトのアクションは続行されます
警告により、ユーザーは更新/挿入を中止できますが、デフォルトのアクションはキャンセルです
エラーは、通常はデータの整合性に関連する必須のビジネスルールに違反し、強制的に更新/挿入はキャンセルされますが、ユーザーは送信されたデータを変更して再試行することを選択できます
致命的は、ユーザーが修正できないものです（データベースへの接続が失われた、ユーザー権限が取り消された、フォームにデータが入力されてからデータが変更されたなど）。トランザクションを強制的に中止します

これが私がやろうとしていることの例です。

シーズンコードを設定するためのフォーム

  • コード
  • 説明
  • 開始日
  • 終了日

必要な検証には次の2つのタイプがあります。

必須：例：コードと説明は完全で一意である必要があります。開始日は終了日より前である必要があります

オプション：通常、開始日と終了日は連続しています。つまり、次のシーズンの開始日は前のシーズンの終了日の翌日ですが、常にそうであるとは限りません。エラーが発生した可能性があることをユーザーに警告し、入力したデータが正しいことを確認してもらいたいと思います。彼らが確認した場合、私は再提出の検証ルールを無視する必要があります。

ユーザーが問題をOKと確認した場合にのみ再送信時に設定されるオプション（情報と警告）を無視するためのストアドプロシージャの追加パラメーターを考えています。ErrorとFatalを使用すると、更新は失敗します。

誰かがより良い代替案を提案できますか？

4

1 に答える 1

0

必要なのは実行タイプのビジネス ルールだけです。これは、ルールが True と評価された場合にメソッド (ルール アクション) を呼び出すものです。アクションはパラメーター (たとえば、列挙型 ErrorLevel) を取り、それに応じて動作し、エラーのログ記録、ユーザーへの通知、ユーザーのエントリの保存などを行うことができます)。何かのようなもの：

If UserRole is Admin and (StartDate is less than or equal to EndDate)
then Prosess(ErrorLevel.Info)
else Abort(ErrorLevel.Fatal)
于 2012-05-09T12:21:28.173 に答える