テーブルの更新時に、.NETコードでアクションをトリガーします

あなたはいくつかの質問をする必要があります。

dbレベルでビジネスロジックをまったく使用しないようにしますか？明らかに、dbトリガーでこれを実行できます（非常に特定の値のみであっても、値が変更されたときに何らかのアクションを実行します）。

私はdbトリガーが重いいくつかのシステムを見てきました。それらの「ロジック」は、dbプラットフォームと深く高度に結合されています。これにはいくつかの利点がありますが、ほとんどの人はおそらく欠点が大きすぎると言うでしょう（結合、カプセル化/再利用性の欠如）。

あなたがしていることとあなたの傾向に応じて、あなたは次のことができます：

1. すべてのDAO/BusinessFunctoinオブジェクトが「イベント」object.functionを呼び出すことを確認してください 特定の値の変更が発生したときに必要なことを実行します。

2. トリガーを使用して、「イベント」object.functionを呼び出します 特定の値の変更が発生したとき。

3. トリガーがすべてを行います。

私は個人的に、最小限のトリガー（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を呼び出すことができます。 必要に応じて。

データベースに直接アクセスすることとトリガーを追加することの主な違いは、一緒にデプロイすると、プロジェクト内のすべてのオブジェクトにアクセスできることです。