これが可能かどうか疑問に思います。特定のテーブルの値が更新されたときに、.NETコードで関数が機能するようにします。これは、レコードの挿入または更新時に発生する可能性があります。これは可能ですか?そうでない場合、代替プロセスはありますか?
あなたはいくつかの質問をする必要があります。
Dbレベルのビジネスロジックを必要としませんか?明らかに、dbトリガーはこれを行うことができます(非常に特定の値のみであっても、値が変更されたときに何らかのアクションを実行します)。
私はdbトリガーが重いいくつかのシステムを見てきました。それらの「ロジック」は、dbプラットフォームと深く高度に結合されています。これにはいくつかの利点がありますが、ほとんどの人はおそらく欠点が大きすぎると言うでしょう(結合、カプセル化/再利用性の欠如)。
あなたがしていることとあなたの傾向に応じて、あなたは次のことができます:
すべてのDAO/BusinessFunctoinオブジェクトが「イベント」_object.function
_を呼び出して、特定の値の変更が発生したときに必要な処理を実行するようにします。
特定の値の変更が発生したときに、トリガーを使用して「イベント」_object.function
_を呼び出します。
あなたのトリガーはすべてを行います。
私は個人的に、最小限のトリガー(_object.function
_へのイベント呼び出しを発生させるだけ)があるオプション2に傾倒するので、データベースをビジネスロジックに深く結び付けません。
オプション1は問題ありませんが、監視したいこのdbtable.fieldと通信するBF/DAOの非常に狭いセットがない限り、少し面倒かもしれません。
オプション3は、ロジックをデータベースに結合し、ビジネスロジックレイヤーへのアクセスを減らすため、最悪の選択です。
それを踏まえて、オプション2を介してこれを達成するためのいくつかの情報があります:
MSDNのこの例を使用する: http://msdn.Microsoft.com/en-us/library/938d9dz2.aspx 。
これは、トリガーを実行してプロジェクト内のCLRオブジェクトを呼び出す方法を示しています。
事実上、プロジェクトでは、トリガーを作成し、それがクラスを呼び出すようにします。
次の行に注意してください:[SqlTrigger(Name="UserNameAudit", Target="Users", Event="FOR INSERT")]
これは、コードがいつ起動するかを定義し、コード内で制約を確認してから、メソッドの残りの部分を起動する(またはしない)か、必要に応じて別の_object.method
_を呼び出すことができます。
データベースに直接移動することとトリガーを追加することの主な違いは、一緒にデプロイすると、プロジェクト内のすべてのオブジェクトにアクセスできることです。
私はこれを試したことがありませんが、可能です。 CLRアセンブリを記述し、それをテーブルトリガーから呼び出すことができます。
あなたは例を見ることができます ここ 。
しかし問題を投稿する必要があり、より良い回避策が見つかる可能性があります。