伐木立面的意义何在?[关闭]

我将主要从使用抽象来将应用程序代码与特定日志框架隔离的角度来讨论。还有其他一些因素可能会影响人们对日志框架的选择或对抽象的选择(以及对抽象的需求)。

有些人认为将他们的应用程序代码与特定的日志框架隔离是有价值的。你会在这里找到很多这样的帖子 this 和 this 和 this

显然,这使您不必绑定到特定的框架。这很重要吗?你真的会改变你的日志框架吗?嗯,也有很多人要么不提包装,要么建议反对包装。如果你看看这里发布的日志框架包装代码的一些例子,你还可以看到许多例子,说明为什么至少有些人不应该包装他们的日志框架!

如果您最近启动了一个项目,那么您可能已经检查了日志框架,并可能将其缩小到两个最终版本:log4net和NLog。每个人都有对自己有利的论据。log4net显然是最受欢迎的,可能是那些表达过观点的人的最爱。NLog提供了非常相似的能力。从受欢迎程度来看,log4net可能是一个明确的选择。基于能力,它们看起来非常相似。基于“最近的活动”(如通过blog活动签入他们的源代码报告或缺少),NLog是明确的选择。如果一年前你不得不选择,你可以选择log4net,因为它是“安全”的选择。目前还不清楚NLog何时释放。在这一年里,NLog经历了一个相当重要的开发周期,几天前刚刚发布了一个beta版本。

一年前该选哪一个?现在该选哪一个?一个显然是更好的选择吗?现在有更好的选择吗?

Common.Logging 或 SLF 允许您现在开始编写代码,对某些日志接口/API进行编码,并将日志代码准备就绪。如果您认为抽象提供的接口/API对于您的工作来说已经足够了(而且,为什么不相信呢,因为它本质上与log4net和NLog提供的接口/API相同),那么使用抽象并没有太大的危险。当您经历开发周期时,您可能会发现一个或另一个框架更适合您的需要。在编写了抽象代码之后,您可以在任何时候自由地进行选择,直到您的产品推出为止。

Ukadc.Diagnostics (获得类似于log4net或NLog的输出格式化功能),这样您就可以“更好地”与微软使用tracesource在其某些平台上实现的日志集成。根据tracesource编写一个“logger”,然后编写抽象以便将其插入到普通。日志记录或者SLF。(如果接口/API足够了,您可以根据抽象库的接口编写“记录器”,而不必编写额外的抽象层)。

有了这些有说服力的论据,为什么会有人不使用抽象?哈哈,开玩笑吧!

如果抽象是好的,你应该自己写还是使用现有的?如果你自己写一个,那么你显然必须要写。怎么做到的?好吧,你可以定义一个接口并包装一个框架(小心并正确包装它!)。稍后,如果您决定要切换,请包装该框架。如果您很小心,您不必更改任何应用程序代码,除了实际创建底层框架对象的位置。也许这很好。您已经避免了对某些第三方抽象的依赖,因为在单个框架上实现单个包装器的“小”代价。然而,这是有代价的。除非你有一个好的策略将抽象转换为你的抽象,否则在你写抽象之前,你不可能真正写很多有日志记录的应用程序代码。对两个或多个框架进行测试,以确定哪一个更适合您。要“尝试”的每个框架都需要另一个包装作业。如果您想在框架之间轻松切换(至少在开发周期内),您需要做一些工作来简化它。第三方框架提供了开箱即用的功能。

日志摘要都是肉汁吗?有缺点吗?他们不会那么好吧?

好吧,和往常一样,当你“买”东西或是得到一些免费的东西时,你就得到了可用的东西。日志抽象也不例外。都不是普通。日志记录norslf至少公开了log4net/NLog的一组非常重要的功能,即日志上下文功能(GDC、MDC、NDC)。这些可能是获取足够的记录和格式化信息的关键,使您能够从中获得最大的价值。SLF不提供TraceSource抽象。它也不提供IsXXXEnabled函数。普通。日志记录提供TraceSource抽象。城堡。伐木为log4net和NLog公开GDC/MDC/NDC。它还提供了一个TraceSource抽象。Castle的TraceSource抽象还通过提供“分层”命名功能来增强TraceSource日志记录,类似于log4net和NLog提供的功能。看起来很酷!

目前还不清楚这些平台的路线图。普通。日志记录有一些即将推出的功能在他们的网站上列出,但不清楚何时可以使用。网站上写着“六月”,但是是哪一年?多久监视一次邮件列表?对于SLF,他们的codeplex多久被监控一次?与开发商的有偿工作相比,这些“免费”项目的优先级在哪里?你能负担得起第三方抽象来实现你所需要的特性吗?如果你实现了某个东西,然后将其提交给考虑将其包含在产品中,他们会接受吗?

好的一面是,所有这些抽象的所有源代码都是可用的,因此您只需承担责任,进行任何修复或添加任何增强,而不必花费时间和精力从头创建抽象。你喜欢吗?普通。日志记录但真的想要log4net/NLog-GDC/MDC/NDC?获取Castle的实现并将其添加到普通。日志记录. 喂!一个日志抽象,包含几乎100%的log4net/NLog日志API。你更喜欢SLF但希望它已经被启用了吗?实现这一点的工作并不多。继续,并在GDC/MDC/NDC的时候进行定位。你喜欢城堡吗?(我不太熟悉,不知道在Castle之外使用它有多容易,如果这很重要的话)小心点,我没有用过它,但是看看git上的源代码,它看起来像NLog logger抽象 可能不会 保留呼叫站点信息。

我快完成了。。。

一些第三方日志抽象提供了其他功能。您可能会使用一个库,它是按照log4net实现的。您可能不想使用log4net,或者至少不想与它绑定。普通。日志记录(可能还有SLF)使得捕获log4net日志消息并在抽象中重新路由它们变得相对容易,这样它们就可以被捕获到抽象的底层日志框架的日志流中。SLF可能提供类似的功能。当然,您也可以对现有的日志框架做一些类似的事情,要么开箱即用,要么编写一个定制的log4net Appender、NLog Target,或者系统诊断跟踪器。在我对是否在我的项目中使用第三方日志抽象的特定评估中,这些特性并不是很突出,因为我主要对抽象方面感兴趣。

那么,我该怎么办?我认为保持应用程序代码与特定日志框架隔离是有价值的。对我来说,普通。日志记录虽然缺少一些重要的特性(GDC/MDC/NDC),而且它与Silverlight不兼容,但看起来是一个可靠的抽象选择。这些功能很快就会面世。如果需要的话,我很乐意实现GDC/MDC/NDC。使其与Silverlight兼容可能需要更多的努力,主要是因为我对C#/.NET/Silverlight没有特别的经验。在解决这些问题之前,我们可以用普通。日志记录到位。我们可以花时间开发应用程序,而不是开发另一个日志库或抽象库。如果我们最终不得不自己添加那些缺少的特性,那么,如果我们自己实现了一个日志库或抽象库,那么我们将不得不做大量的工作。

我认为让一个(抽象层次)成为神奇数字的原因是零太少,而二太多。

很难想象用户从交换logger facade(级别数:2)中获益。

(如果级别数是0,那么可能是面向对象的设计不好:在代码中有数千个引用记录器的位置,如果在下一个版本的记录器中发生了重大更改,该怎么办。)

与logger facades的交易似乎是,你必须选择一个第三方选项,或创建自己的,并准备长期坚持下去。

日志facade的一个重要用途是 写图书馆 . 在库中嵌入依赖项总是需要一点小心,日志记录更是如此。

您不希望将日志记录实现强制到库用户身上 . 使用一个精心选择的facade意味着他们可以用自己选择的框架来处理库的日志,而不必经历一些奇怪的依赖排除和漏洞,从而使你的日志框架和他们的日志框架共存。

为什么?

获得所有用户需求的最大测试覆盖率,特别是当这些需求覆盖日志时。

当你的日志记录成为一个非常简单的接口,而不是一个记录你的接口时,你可以通过一个非常简单的接口来记录你的日志。

如果NLog或log4Net要为他们的记录器提供接口,那么我就不需要再去提供接口和包装类了,因为我可以模拟他们的接口进行测试。

在我的项目中我使用 System.Diagnostics.Trace.TraceError(...) , System.Diagnostics.Debug.Print(...) 作为伐木的门面。为了组织(编写)日志,我使用NLog,即应用程序配置我有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。

这不是魔术数字,这取决于你想要有多灵活。 如果你只想改变原木,你需要一个门面。

你说的缺点是特殊能力。如果你正在使用它们,只写你自己的门面。

换掉你的伐木门面还能给你带来什么额外的好处?

它在插件系统的协议中是可用的。而不是说 use Some3rdParty.dll and MyPlugingApi.dll 我只会记录 MyPlugingApi.dll . logfacade接口将建议并记录一些可能会导致可读日志和足够好的日志性能的用法。当然,做改变不会导致插件API的改变。

为什么需要改变实施?如果current从配置开始速度慢,或者写条目速度慢,希望扩展以减少不需要第三方的.NET版本,并与使用其他日志写入程序的其他代码库集成,则可能会发生这种情况。

facade 这是这个答案中思想的产物。

我自己绝不是专家,但在我们的团队中,facade的价值不在于让我们能够更改日志框架。的确,这是我们得到的,但我们属于不太可能改变我们的框架的类别。

在我们的例子中,我们使用facade来定制日志 以满足我们应用的需要。我们发现,在我们所研究的所有语义框架中,它们仍然过于专注于我们称之为“取证”的日志模型——有人在日志中挖掘,寻找一些输出行,试图分析某个事件。

虽然这也是我们的一个用例,但实际上它不是我们的主要用例。我们想要更多的 仪器仪表

为了简洁地给您一个简单的答案,下面是一个粗略的排序顺序,我们认为使用日志facade可以获得哪些好处。

1. 一致的、专门构建的接口 简化仪器(与上面讨论的传统日志记录不同)
2. 模拟测试点
3. 可注入记录器实现
4. 可替代的记录器框架 使我们能够在将来更改为不同的记录器框架,如果我们愿意的话。(顺便说一句,我们并不认为这种情况会发生,因此,单凭这一点,我们不会说服我们使用外观。)

最后,0个门面将失去这些好处,2个门面不会增加这些好处,所以1个门面对我们来说是正确的。

好问题,布莱恩!:)