2009-04-23 15 views
2

私のドメインオブジェクトに直接log4netを使用するのが悪い習慣であるのだろうか...私はASP.NET MVCアプリケーション側で私の例外にELMAHを使用しますが、ドメインモデル自体に関するいくつかのデータドメインモデルオブジェクトでlog4netを直接使用する必要がありますか?

を考えると、次のドメインオブジェクト:これは古典的である

 public class Buyer 
{ 
    protected static readonly ILog log = LogManager.GetLogger(typeof(SupportTicket)); 

    public Buyer() 
    { 
     log4net.Config.XmlConfigurator.Configure(); 
    } 


    private int _ID; 
    public int ID 
    { 
     get { return _ID; } 
     set 
     { 
      _ID = value; 
     } 
    } 

    private IList<SupportTicket> _SupportTickets=new List<SupportTicket>(); 
    public IList<SupportTicket> SupportTickets 
    { 
     get 
     { 
      return _SupportTickets.ToList<SupportTicket>().AsReadOnly(); 
     } 
    } 

    public void AddSupportTicket(SupportTicket ticket) 
    { 
     if (!SupportTickets.Contains(ticket)) 
     { 
      _SupportTickets.Add(ticket); 
     } else { 
      log.Warn("Duplicate Ticket Not Added."); 
     } 
    } 
} 

答えて

1

ドメインオブジェクトからログオンし、スワップアウトする可能性のあるIOCコンテナを使用する場合はService Locatorパターンを使用することをお勧めします(Sharp#アーキテクチャーで、msoftのServiceLocatorをより有益なエラーメッセージでラップするSafeServiceLocatorの優れた実装方法を見てください)。

あなたの例で表示するエラーの種類を記録するかどうかを検討することをお勧めします。その場合、ドメインオブジェクトに例外をスローし、呼び出し側がアプリケーションによって予期されたものであったかどうか(したがってログに記録すべきではない)かどうか、あるいはそれが呼び出し元が望む状況を表すかどうかを判断させたいという傾向があります何らかの方法で対処する。

+3

サービスロケータは、反パターンであり、依存性注入の目的を無効にします。この答えは主観的に間違っているわけではなく、客観的に間違っています。 – jason

+0

私はJasonに同意します。詳細情報:http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx – autonomatt

1

public class Buyer 
{ 
    private int _ID; 
    public int ID 
    { 
     get { return _ID; } 
     set 
     { 
      _ID = value; 
     } 
    } 

    private IList<SupportTicket> _SupportTickets=new List<SupportTicket>(); 
    public IList<SupportTicket> SupportTickets 
    { 
     get 
     { 
      return _SupportTickets.ToList<SupportTicket>().AsReadOnly(); 
     } 
    } 

    public void AddSupportTicket(SupportTicket ticket) 
    { 
     if (!SupportTickets.Contains(ticket)) 
     { 
      _SupportTickets.Add(ticket); 
     } 
    } 
} 

がそう、それは次のようになりたいessentialy ... AddSupportTicketMethodに悪い考えをロギング動作を追加することです質問!

これを行う良い方法は、ILoggerタイプのクラスメンバーを導入し、このインターフェイスにログを抽象化することです。あなたのクラスでは、loggの呼び出しを行うたびに、このインターフェースを通して何かを行います。次に、使用可能なIoCコンテナまたは依存性注入ファームワークのいずれかを使用して、この依存関係を実行時に注入します。デフォルトでは、このインタフェースのlog4net実装を使用することができます。ここで

は、利用可能な依存性注入フレームワークの長いリストである: http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

0

私がログインすると思わ横断的関心事である、それは最高のアスペクト指向の方法で行われています。 Spring.NETのようなフレームワークを使用しているなら、それを利用できます。

3

私はlog4netとlog4Jをドメインオブジェクトで直接使用しています。これは良い副作用と悪いものがあります。

  • +:ドメインオブジェクトのログインは、コードにシンプルで簡単です、あなたはlog4netの機能を利用することができます知っています。
  • -:それはドメインオブジェクトを利用するプログラムがまたは
  • 問題であってもなくてもよい、log4netの設定に注意を払う必要があること -:あなたはにあなたのドメインオブジェクトをリンクすることはできません呼び出し元のプログラムとは異なるlog4netバージョンが使用されています。私は、log4net 1.2.0.10にリンクされた1つのアイテムと、それ以前のリリースとリンクしていたものとの間で、多くの競合を見てきました。

ドメインオブジェクトにを記録しないと悪い考えです。別の方法として、別のロギングフレームワークをプラグインするか、そのインタフェースに対してロギングとロギングを行うインタフェースを作成する外部フレームワーク(log4Jのコモンログなど)があります。ドメインオブジェクトを使用しているコードは、ロギング目的でそのインタフェースの適切なインスタンスを提供する必要があります。

関連する問題