1

私はEFを使用してMVC3アプリで何らかの監査動作を構築しています。コードへの大きな影響を回避するために、そしてもちろん、できるだけ多くの余分なコードを回避するために、いくつかのアプローチを試しました。アプリケーションは35%で完了しているためです。

Auditオブジェクトは次のようになります。

  • AuditId
  • ユーザーID
  • OperationId
  • ModuleId
  • タイムスタンプ
  • ペイロード
  • <モジュール>
  • <操作>
  • <ユーザー>

アイデアは次のようになります。

SaveChanges()を非表示にしてオーバーライドする部分クラスを作成しましたSaveChanges(SaveOptions)

次に、同じメソッドのオーバーロードをさらに2つ作成して、エンティティをパラメーターとして受け取るか、SaveOptions列挙型パラメーターとして受け取らないようにしました。

明らかなことに加えて、新しいものは私のエンティティSaveChanges()のプロパティを設定しますが、問題はここで発生します: 、、およびが必要です。AuditUserModuleOperation

これを解決するための私の現在の解決策は次のとおりです。

  • Auditコンストラクタークラスレベルでオブジェクトを宣言しました。
  • コントローラのコンストラクタでUserAuditオブジェクトにを設定しました。
  • それぞれの方法でOperation、必要に応じて設定しました。
  • 変更の保存では、からのペイロード(私の場合はxml)を処理しObjectStateManagerます。

I'm very skeptic about this approach, it seems to be a little intrusive to my code. I've read lots of posts here in SO, but none of them helped me to improve this approach nor decide to change it. So please avoid linking things I've probably already read.

4

1 に答える 1

2

もう1つのオプションは、監査するデータベースエンティティをカスタム属性で装飾することです。SaveChanges中に属性を確認してください。モジュールフィールドと操作フィールドについては、その時点でスタックトレースをキャプチャできます。呼び出し元のコントローラーと、そこからアクションを見つけます。これにより、コントローラーをよりクリーンに保つことができます。

私は、監査ではなく、列レベルで監査を行います。通常、私は全体ではなく、いくつかの列だけを気にします。参考までに、これが私のベースDbContextです。ObjectContext.SavingChangesイベントをサブスクライブし、変更済みとしてマークされたすべてをチェックしてから、カスタム[Audit]属性を持つプロパティをチェックします。これは簡単に拡張して、削除をチェックすることもできます。

于 2012-08-23T16:54:05.940 に答える