2

したがって、このデータアクセス層があり、データベースにもログインしたいと思います。自分のドッグフードを食べるという精神で、データアクセス層を使用してログを記録したいと思います。ただし、データアクセス自体もログに記録したいと思います。そのようです：

App
||
V
Log
||
V
Data=>Log

フィードバックループに入るリスクはありますか？もしそうなら、どうすればそれを避けることができますか？プロジェクトの参照が相互にループし、構築が困難になる可能性がありますか？過去にこの（アンチ？）パターンにどのようにうまくアプローチしましたか？

4

2 に答える 2

1

インターフェイスのみを含むアセンブリ (場合によってはアセンブリ) を作成します。具象クラス アセンブリからインターフェイスのみのアセンブリを参照し、すべての具象クラスに 1 つ以上のインターフェイスを実装させます。具象クラス アセンブリが、ソリューションの一部である他の具象クラス アセンブリを参照しないようにします。

このアプローチは、循環依存を回避するのに役立ちます。

StructureMapのようなコントロール コンテナーの依存性注入/反転を実装するか、結合をさらに減らすために利用可能な他の多くの .NET オプションの 1 つを実装します。

于 2009-12-15T17:44:26.180 に答える
1

おそらく過度に単純化されたソリューション：

public interface ILoggable {
    string ToLogFormat();
}

次に、ログに記録できる任意のオブジェクトにこのインターフェイスを実装します。ロギング レイヤーはインターフェイスのみに依存するようになり、どのレベルでも使用できるようになりました。

別の方法は、「ヘルパー」クラスを使用して、オーバーロードを介して ToLogFormat を実装することです。

public class LogHelper {
    public string ToLogFormat(DAO obj) { ... }
    public string ToLogFormat(SomeOtherClass obj) { ... }
    ...
}

1 つのモノリシック ログ ヘルパーを使用することもできますが (すべてのライブラリを参照する必要があるため、これは不適切です)、アセンブリまたはクラスごとにログ ヘルパーを実装し、カスタム属性を使用してログ ヘルパー クラスの名前を指定することをお勧めします。

個人的には、より柔軟な ILoggable アプローチを好みます。logging パッケージには、次のような単純な機能を含めることができます。

public class Logger {
    public string ToLogFormat(object obj) {
        if (obj is ILoggable) {
            return ((ILoggable)obj).ToLogFormat();
        }
        return obj.ToString();
    }
}
于 2009-12-15T18:04:04.127 に答える