3

何らかの監査を行う必要があります。レコードが挿入、更新、削除、または開かれたときに保存したいと考えています。

今のところ、Singleton クラスで単純なメソッドを作成しました。

public void Audit(string audit, AuditTypes type)
{
    AuditEntry = new AuditEntry(){ Audit = audit, TypeId = (int)type };

    // some logic to commit the audit entry to the database
}

public enum AuditTypes
{
  Insert = 1,
  Update = 2,
  Delete = 3
  Open = 4
}

フォームのどこかで、このメソッドを呼び出します。

MyForm.cs:

private void RemoveSomeObject(SomeObject myObject)
{
   /* Do some stuff that removes the object*/

   MySingleton.GetInstance().Audit(myObject.Title, AuditTypes.Delete)
}

何らかの理由で、コードのどこでもこのアプローチを使用すると、この種の行があるため、これが進むべき道だとは思いません。

よりOOの方法で行う方が賢明だと思いますが、どう思いますか? 編集：

ユーザー ID と日付をログに記録していますが、通知する必要はありませんでした。

4

4 に答える 4

2

CRUD タイプのアクションを実行するときは、多くの場合、リポジトリ デザイン パターンを使用してデータ アクセス レイヤーをカプセル化することをお勧めします。監査を処理する Repository クラスの基本クラスを作成できます。

于 2012-02-03T13:51:46.857 に答える
2

これは、アスペクト指向プログラミングの典型的な例です。基本的に、システムの多くの部分 (ロギングや監査など) に広がる分野横断的な要件があります。問題は、あなたのアプローチは正しいように見えますが、保守が難しく、うまくスケーリングできない可能性があることです。時間があり、そうしたい場合は、これについて読んで、PostSharpを使用して試してみることができます。無料のスターター エディションがあります。これも確認できます: AOP in .NET

于 2012-02-03T14:25:20.050 に答える
1

まあ、あなたは確かにシングルトン（その固有の悪さのためにグーグル）を避けるべきです、しかし私は確かにあなたのアプローチに他に多くの間違いがあるとは思いません。そして、読みやすさ、パフォーマンス、正確さなどの重要な要素に対してコードを改善できる場合は、OOの方法で何かを行う方が賢明です。OO-nessはそれほど重要ではありません。

したがって、シングルトンを回避するために、監査が必要な操作を実行するたびに、監査人のインスタンスを注入します。

private void RemoveSomeObject(SomeObject myObject, Auditer myAuditer)
{
    // do stuff //

    myAuditer.Audit(...);
}

（ちなみに、フォームから削除ロジックも削除して、別のレイヤーに配置する必要があります。各クラスには1つの責任しかありません）

于 2012-02-03T13:44:34.420 に答える
0

監査オブジェクトへのメソッド呼び出しの数を減らすために、データ層内で可能な限り低いレベルで監査を行うことをお勧めします。

監査の経験から、変更前と変更後のイメージ、変更日時、および変更者のコピーを保管しておくと便利であることがわかりました。

于 2012-02-03T13:48:30.343 に答える