相关疑难解决方法(0)

我有兴趣了解更多有关人们如何使用依赖注入平台注入日志记录的信息.虽然下面的链接和我的示例引用了log4net和Unity,但我不一定会使用其中任何一个.对于依赖注入/ IOC,我可能会使用MEF,因为这是项目的其余部分(大)正在解决的标准.

我是依赖注入/ ioc的新手,对于C#和.NET来说还是新手(在过去10年左右的VC6和VB6中,在C#/ .NET中编写了很少的生产代码).我已经对各种日志解决方案进行了大量调查,所以我认为我对其功能集有一个不错的处理.我只是不熟悉获得一个依赖注入的实际机制(或者,可能更"正确",获得一个依赖注入的抽象版本).

我见过其他与日志记录和/或依赖注入相关的帖子,如: 依赖注入和日志记录接口

记录最佳实践

Log4Net Wrapper类看起来像什么？

再次关于log4net和Unity IOC配置

我的问题与"如何使用ioc工具yyy注入日志记录平台xxx"无关？相反,我感兴趣的是人们如何处理包装日志记录平台(通常,但并不总是建议)和配置(即app.config).例如,使用log4net作为示例,我可以配置(在app.config中)一些记录器,然后以标准方式使用这样的代码来获取这些记录器(没有依赖注入):

private static readonly ILog logger = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

或者,如果我的记录器没有为某个类命名,而是为了一个功能区,我可以这样做:

private static readonly ILog logger = LogManager.GetLogger("Login");
private static readonly ILog logger = LogManager.GetLogger("Query");
private static readonly ILog logger = LogManager.GetLogger("Report");

所以,我想我的"要求"将是这样的:

1. 我想将我的产品源与直接依赖于日志记录平台隔离开来.

2. 我希望能够通过某种依赖注入(可能是MEF)直接或间接地解析特定的命名记录器实例(可能在同一命名实例的所有请求者之间共享相同的实例).

3. 我不知道我是否会称之为硬性要求,但我希望能够根据需要获得一个命名记录器(不同于类记录器).例如,我可能会根据类名为我的类创建一个记录器,但是一个方法需要特别重的诊断,我想单独控制.换句话说,我可能希望单个类"依赖"两个独立的记录器实例.

让我们从数字1开始.我已经阅读了很多文章,主要是关于stackoverflow,关于它是否是一个好主意.请参阅上面的"最佳实践"链接,并转到jeffrey hantin的评论,了解一个关于为什么包装log4net不好的观点.如果你确实包装(如果你能有效地包装),你会严格包装以注入/消除直接的倾向吗？或者你也会尝试抽象出部分或全部log4net app.config信息？

假设我想使用System.Diagnostics,我可能想要实现一个基于接口的记录器(甚至可能使用"常见的"ILogger/ILog接口),可能基于TraceSource,以便我可以注入它.你会实现接口,比如TraceSource,只是按原样使用System.Diagnostics app.config信息吗？

像这样的东西:

public class MyLogger : ILogger
{
  private TraceSource ts;
  public MyLogger(string name)
  {
    ts = new TraceSource(name);
  }

  public void ILogger.Log(string msg)
  {
    ts.TraceEvent(msg);
  }
} …

有没有人使用微软的托管可扩展性框架(MEF)？有点听起来它试图成为所有人的所有事情 - 这是一个加载项管理器!这是鸭子打字!我想知道是否有人有经验,积极或消极.

我们目前正在计划为我们的下一个大项目使用通用的IoC实现ala MvcContrib.我们应该把混合物中的MEF扔掉吗？