有许多不同的日志记录库可供选择，每个库都有自己的怪癖和优点。（.NET示例：log4net、System.Diagnostics.TraceSource、NLog等）
自然的倾向是抽象出这些怪癖并使用一个日志记录门面（facade）。 （例如：Castle.Services.Logging，Common.Logging，简单日志门面）这样，如果您正在使用的某个日志记录框架过期或者有新的框架进入流行，您只需要更换实现而不改变代码。
但是，还有多个日志记录门面可供选择。鉴于许多不同的日志实现都采用了抽象方式，为什么不使用一个日志记录门面的门面呢？ 如果这听起来荒谬，那么它比原始日志门面更荒谬在哪里？ 一个额外的抽象层对日志框架的控制有何神奇之处？
那么，我的立场是什么？我认为将应用程序代码与特定的日志记录框架隔离开是有价值的。对我来说，Common.Logging看起来是一个很好的抽象选择，尽管缺少一些重要的功能（GDC/MDC/NDC）并且不兼容Silverlight。如果这些功能很快可以获得将会很棒。如果必须的话，我可以很容易地实现GDC/MDC/NDC。使其兼容Silverlight可能需要更多的努力，主要是因为我对C#/.NET/Silverlight不是特别熟悉。在这些问题得到解决之前，我们将能够使用Common.Logging编写大量的应用程序代码。我们可以花时间开发我们的应用程序而不是再开发另一个日志记录库或抽象库。如果最终必须自己添加这些缺失的功能，那么我们就必须做很多工作，就像我们如果自己实现日志记录库或抽象库一样。
我认为“一”（抽象级别）是这里的魔数，因为“零”太少，“二”太多。
在日志记录器门面后面交换日志记录器（级别数：1）可能会带来一些用户受益，例如新的日志记录器可以做一些旧的日志记录器无法做到的事情。我可以想象它可能是性能、支持某些类型的附加程序等方面。
很难想象从交换日志记录器门面（级别数：2）中获得用户受益。
（如果级别数为0，则可能只是糟糕的面向对象设计：您的代码中将有数千个地方引用日志记录器，如果下一个版本的日志记录器有破坏性变化怎么办。）
日志记录器门面的问题似乎是你必须选择第三方选项之一或创建自己的选项并准备长期使用它。
日志门面的一个重要用途是在您编写库时。嵌入依赖库始终需要一些小心，尤其是日志。
简而言之，您不希望将日志实现强加给库用户。使用一个选择得当的门面意味着他们将能够处理您库的日志与他们自己选择的框架，并且不必经过一些奇怪的依赖排除和漏洞来使您的日志框架和他们的框架共存。
在我的项目中，我使用System.Diagnostics.Trace.TraceError(...)和System.Diagnostics.Debug.Print(...)作为记录日志的外观。为了组织（编写）日志，我使用NLog，也就是说，在app.config文件中，我有NLog的配置和将.net的跟踪重定向到NLog。
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="file" xsi:type="File"
layout="${longdate:universalTime=true}Z [${threadid}] ${pad:padding=5:inner=${level:uppercase=true}} ${logger} ${message}"
fileName="${basedir}/App_Data/logfile.txt"...
</targets>
</nlog>
<system.diagnostics>
<trace>
<listeners>
<add name="nlog" type="NLog.NLogTraceListener, NLog" />
</listeners>
</trace>
</system.diagnostics>
这不会使我与任何日志记录器捆绑在一起。当我向客户交付我的组件时，他们可以使用任何他们喜欢的日志记录器。在应用程序中使用特定的日志记录器可能会导致问题，例如，您可以使用nlog，但是您的客户使用log4net。
这不是魔数，而是取决于你想要多灵活。 如果你考虑将来更改日志门面，那么你应该编写一个门面门面。 如果你只考虑更改日志，则只需要一个门面。 如果你什么都不考虑，就不要使用门面。
正如你所说的，缺点在于特殊能力。如果你正在使用它们，请编写自己的门面。
它可用于插件系统的协议中。不需要说“使用Some3rdParty.dll和MyPlugingApi.dll”，我只需记录 MyPlugingApi.dll 。日志门面接口将建议和记录某些使用方式，这可能会导致可读的日志和足够好的日志性能。而且，更改不会导致对插件API的更改。
为什么需要更改实现？如果当前配置文件启动速度缓慢或写入条目速度缓慢，希望扩展为没有所需第三方组件的.NET的缩小版本，与使用其他日志编写程序的其他代码库集成等情况下，就可能发生这种情况。
我还编写了另一个facade，它是本答案中思想的子代。
我本人并不是专家，但在我们的团队中，门面的价值不在于让我们能够更改日志框架。当然，这是我们得到的一些东西，但我们属于那种非常不可能更改框架的类别。
在我们的情况下，我们使用门面来定制日志接口以满足我们应用程序的需求。我们发现，在我们查看的所有语义框架中，它们仍然过于关注我们所称的“取证”模型的日志记录——有人在日志中寻找某些输出行，试图分析某个事件。
虽然这也是我们的一个用例，但实际上并不是我们的主要用例。我们希望拥有更多的“仪表化”框架而不是日志框架，这将使我们能够报告感兴趣的事物，甚至是我们在实施时没有想到的事物。
例如，我们的应用程序不需要“消息”来伴随事件；相反，我们的“记录器”将接受定义事件类型的枚举和表示特定状态对象（例如时间戳或其他值），并将这些序列化以便于报告、性能分析、业务价值指标等等，除了支持传统的取证。 （我们认识到，事实上，为了获得易于使用和理解的日志记录界面，增加我们实际使用它并经常使用它的可能性，我们正在使传统的取证变得更加困难）。最后，0个外观会失去这些好处，2个外观不会增加任何这些好处，所以对我们而言，1个外观是正确的数字。
很棒的问题，@brian！ :)