ロガーをシングルトンにするのは良い習慣ですか？

次のように、ロガーをコンストラクターに渡す習慣がありました。

public class OrderService : IOrderService {
     public OrderService(ILogger logger) {
     }
}

しかし、それは非常に面倒なので、私はしばらくの間、これをプロパティとして使用しました。

private ILogger logger = NullLogger.Instance;
public ILogger Logger
{
    get { return logger; }
    set { logger = value; }
}

これも面倒になります-乾いていないので、すべてのクラスでこれを繰り返す必要があります。基本クラスを使用することもできますが、Formクラスを使用しているので、FormBaseなどが必要になります。したがって、ILoggerを公開したシングルトンを使用することのデメリットは何でしょうか。

    Infrastructure.Logger.Info("blabla");

更新：マーリンが正しく気づいたように、最初と2番目の例ではDIを使用していることを言及する必要があります。

これも迷惑になっています-それはDRYではありません

それは本当だ。しかし、あなたが持っているすべてのタイプに蔓延する横断的関心事に対してできることはたくさんあります。どこでもロガーを使用する必要があるため、これらのタイプのプロパティが必要です。

それで、私たちがそれについて何ができるか見てみましょう。

シングルトン

シングルトンはひどい<flame-suit-on>です。

2番目の例で行ったように、プロパティインジェクションを使用することをお勧めします。これは、魔法に頼らずにできる最高のファクタリングです。シングルトンを介して非表示にするよりも、明示的な依存関係を設定することをお勧めします。

しかし、シングルトンがあなたがしなければならないすべてのリファクタリング（水晶玉の時間！）を含めてあなたにかなりの時間を節約するなら、私はあなたがそれらと一緒に暮らすことができるかもしれないと思います。シングルトンの使用があったとしたら、これはそれかもしれません。あなたがあなたの考えを変えたいと思うならば、それが得るのと同じくらい高くなるであろうコストを覚えておいてください。

これを行う場合は、Registryパターン（説明を参照）を使用して他の人の回答を確認し、シングルトンロガーインスタンスではなく（リセット可能な）シングルトンファクトリを登録している人を確認してください。

それほど妥協することなく同様に機能する可能性のある他の選択肢があるので、最初にそれらをチェックする必要があります。

VisualStudioコードスニペット

Visual Studioコードスニペットを使用して、反復的なコードの入力を高速化できます。のようなものを入力できるようloggertabになり、コードが魔法のように表示されます。

AOPを使用してドライオフ

PostSharpのようなアスペクト指向プログラミング（AOP）フレームワークを使用してその一部を自動生成することにより、そのプロパティインジェクションコードの一部を削除できます。

完了すると、次のようになります。

[InjectedLogger]
public ILogger Logger { get; set; }

また、メソッドトレースサンプルコードを使用して、メソッドの開始コードと終了コードを自動的にトレースすることもできます。これにより、ロガープロパティの一部をまとめて追加する必要がなくなる可能性があります。クラスレベルまたは名前空間全体で属性を適用できます。

[Trace]
public class MyClass
{
    // ...
}

// or

#if DEBUG
[assembly: Trace( AttributeTargetTypes = "MyNamespace.*",
    AttributeTargetTypeAttributes = MulticastAttributes.Public,
    AttributeTargetMemberAttributes = MulticastAttributes.Public )]
#endif

依存性注入コンテナにロガーインスタンスを配置します。これにより、ロガーが必要なクラスに注入されます。

良い質問。ほとんどのプロジェクトのロガーはシングルトンだと思います。

いくつかのアイデアが頭に浮かびます。

• 使用のServiceLocator（または他の依存性注入すでにいずれかを使用している場合、コンテナ）シングルトンだろう明らかであるあなたがのServiceLocator経由でロガーや複数の異なるロガーとシェアをインスタンス化することができ、このように、サービス/クラス全体で共有ロガーにあなたを可能に、ある種の制御の反転。このアプローチにより、ロガーのインスタンス化および初期化プロセスに大きな柔軟性がもたらされます。
• ほとんどどこでもロガーが必要な場合-Objectタイプの拡張メソッドを実装して、各クラスが、、などのロガーのメソッドを呼び出せるようLogInfo()にしますLogDebug()。LogError()

シングルトンは良い考えです。さらに良いアイデアは、レジストリパターンを使用することです。これにより、インスタンス化をもう少し制御できます。私の意見では、シングルトンパターンはグローバル変数に近すぎます。オブジェクトの作成または再利用を処理するレジストリを使用すると、インスタンス化ルールを将来変更する余地があります。

レジストリ自体を静的クラスにして、ログにアクセスするための簡単な構文を与えることができます。

Registry.Logger.Info("blabla");

単純なシングルトンは良い考えではありません。ロガーの交換が難しくなります。私はロガーにフィルターを使用する傾向があります（一部の「ノイズの多い」クラスは警告/エラーのみをログに記録する場合があります）。

ロガーファクトリのプロキシパターンと組み合わせたシングルトンパターンを使用します。

public class LogFactory
{
    private static LogFactory _instance;

    public static void Assign(LogFactory instance)
    {
        _instance = instance;
    }

    public static LogFactory Instance
    {
        get { _instance ?? (_instance = new LogFactory()); }
    }

    public virtual ILogger GetLogger<T>()
    {
        return new SystemDebugLogger();
    }
}

これにより、コードを変更せずに（したがって、オープン/クローズの原則に準拠して）、FilteringLogFactoryまたはを作成できますSimpleFileLogFactory。

サンプル拡張

public class FilteredLogFactory : LogFactory
{
    public override ILogger GetLogger<T>()
    {
        if (typeof(ITextParser).IsAssignableFrom(typeof(T)))
            return new FilteredLogger(typeof(T));

        return new FileLogger(@"C:\Logs\MyApp.log");
    }
}

そして、新しい工場を使用するには

// and to use the new log factory (somewhere early in the application):
LogFactory.Assign(new FilteredLogFactory());

ログに記録する必要があるクラス：

public class MyUserService : IUserService
{
    ILogger _logger = LogFactory.Instance.GetLogger<MyUserService>();

    public void SomeMethod()
    {
        _logger.Debug("Welcome world!");
    }
}

.NETには依存性注入という本があります。必要なものに基づいて、傍受を使用する必要があります。

この本には、コンストラクター注入、プロパティ注入、メソッド注入、アンビエントコンテキスト、インターセプトを使用するかどうかを決定するのに役立つ図があります。

これが、この図を使用する理由の1つです。

1. 依存関係がありますか、それとも必要ですか？- それが必要
2. 横断的関心事ですか？- はい
3. あなたはそれからの答えが必要ですか？- 番号

インターセプトを使用する

私が個人的に最も簡単だと思うもう1つの解決策は、静的Loggerクラスを使用することです。プロパティインジェクションの追加など、クラスを変更せずに、任意のクラスメソッドから呼び出すことができます。非常にシンプルで使いやすいです。

Logger::initialize ("filename.log", Logger::LEVEL_ERROR); // only need to be called once in your application

Logger::log ("my error message", Logger::LEVEL_ERROR); // to be used in every method where needed

あなたがログインするための良い解決策を見てみたいなら、私はあなたがロギングが同じくらい簡単ようであるのpythonでのGoogleのApp Engineで見てくださいimport logging、その後、あなたができるばかりlogging.debug("my message")か、logging.info("my message")それが必要として本当に簡単として、それを維持しています。

Javaにはロギングに適したソリューションがありませんでした。つまり、log4jは、ここで回答されているように「ひどい」シングルトンを使用することを実際に強制するため、避ける必要があります。ダブルロギングの理由が、同じ仮想マシンの2つのクラスローダーに1つのシングルトンのロギングオブジェクトがあるためだと思われる場合（！）

C＃にそれほど固有ではないことをお詫びしますが、C＃を使用したソリューションは、log4jがあったJavaに似ているので、シングルトンにする必要があります。

だから私はGAE / pythonのソリューションが本当に好きでしたそれは可能な限りシンプルで、クラスローダーについて心配する必要はなく、ダブルロギングステートメントやデザインパターンを取得する必要もありません。

この情報の一部があなたに関連していることを願っています。実際のシングルトンを持つことができないためにシングルトンが疑われる問題の量をいじめる代わりに、私が推奨するIロギングソリューションを見てみたいと思います。いくつかのクラスローダーでインスタンス化されている必要があります。