0

NLog を統合するには、インターフェイスを定義したいと考えており、2 つのアプローチを検討しています。C#を使用しています。

アプローチ 1:

public interface ILoggingManager
{
    void DoErrorLogging(type , string ) 
    void DoErrorLogging(type , string  , exception ) 

    void DoTraceLogging(type , string ) 
    void DoTrace Logging(type , string  , exception ) 

    // And so on for all the types that Nlog supports.
     .... 
    // Finally would have 10 methods defined in this interface. 
}

アプローチ 2:

//Have an Enum defined for the logging levels
public enum LoggingLevel
{
    Error,
    Warn,
    Info,
    Debug,
    Trace
}

public interface ILoggingManager
{
    void DoLogging(type , LoggingLevel , string ) 
    void DoLogging(type , LoggingLevel   , exception ) 
}

質問:

  1. 設計原則 (SOLID など) を念頭に置いたより良いアプローチはどれですか?
  2. パフォーマンスの観点から、どのアプローチがより良いアプローチですか?
4

1 に答える 1

0

私の答えは直接的な解決策を提供しませんが、それでも...

すべてのインターフェイスを含む既存のロギング フレームワークを使用します。残りは構成です（または構成する必要があります）。

log4netまたはslfのいずれかを使用することをお勧めします

独自のインターフェイスを主張する場合、ここではパフォーマンスはまったく問題ではないと思います。列挙値を NLog の適切なメソッドにマップするか (アプローチ 2)、直接使用します (アプローチ 1)。

アプローチ 2 は間違いなくずっとクリーンです。私はそれを少し変更します：

public interface ILoggingManager
{
    void DoLogging(type , LoggingLevel , string, /* optional */ exception ) 
}

アプローチ 2 で得られるメリットについて説明します。使用しようとしているログ レベルを事前に把握していない場合があります。例外を検査しているとしましょう。で終わることもあれば、で終わることもありWarnますError。アプローチ 2 を使用する場合、コードの再利用はより簡単です。関連する列挙値を選択するだけで準備完了です。アプローチ 1 を使用する場合、コードの再利用Actionには関連するメソッドへの のマッピングとそれの呼び出しが含まれる可能性があり、これにより全体が少し複雑になりすぎてログに記録できなくなります...

ところで、typeここは何ですか？消費クラスのタイプ？

于 2013-09-30T06:59:25.697 に答える