伐木立面的意义何在? [英] What's the point of a logging facade?

问题描述

有许多不同的日志库可供选择，每个库都有自己的特点和优势.(.NET 示例:log4net、System.Diagnostics.TraceSource、NLog 等)

There are a bunch of different logging libraries to choose from, each with their own set of quirks and advantages. (.NET examples: log4net, System.Diagnostics.TraceSource, NLog, etc.)

自然倾向是抽象掉那些怪癖并使用日志外观.(示例:Castle.Services.Logging,Common.Logging、Simple Logging Facade) 这样，如果您使用的给定日志框架变得陈旧，或者不同的日志框架变得流行，您可以更换实现并保持代码不变.

The natural inclination is to abstract away those quirks and use a logging facade. (examples: Castle.Services.Logging, Common.Logging, Simple Logging Facade) That way, if a given logging framework that you're using goes stale, or a different one comes into vogue, you can just swap out the implementation and leave the code untouched.

但是有多个日志外观可供选择.鉴于许多不同的日志实现的答案是抽象，为什么不使用日志门面?如果这听起来很荒谬，是什么使它比原来的伐木外观更荒谬?是什么让日志框架之上的额外抽象层成为幻数?

But there are multiple logging facades to choose from. Given that the answer to many disparate logging implementations was abstraction, why not use a logging facade facade? If that sounds ridiculous, what makes it more ridiculous than the original logging facade? What makes one extra layer of abstraction on top of the logging framework the magic number?

推荐答案

我将主要从使用抽象来将应用程序代码与特定日志框架隔离的角度进行发言.还有其他因素会影响一个人对日志框架的选择或一个人对抽象的选择(和要求).

I will speak mainly from the perspective of using the abstraction to insulate application code from a particular logging framework. There are other factors that can affect one's choice of logging framework or one's choice of (and requirements for) an abstraction.

我最近花了很多时间评估各种日志框架以及第三方日志抽象.

I have spent a lot of time recently evaluating various logging frameworks as well as third party logging abstractions.

有些人认为将他们的应用程序代码与特定日志框架隔离是有价值的.您会在 SO 上找到许多帖子，例如 this 和 this 和 这个(还有更多)讨论了日志记录，许多人认为日志框架应该被包装/抽象是理所当然的.

Some people feel there is value in insulating their application code from a specific logging framework. You will find many posts here on SO like this and this and this(and there are more) where logging is discussed and many people take it as a matter of course that the logging framework should be wrapped/abstracted.

显然，这允许您不受特定框架的束缚.这很重要吗?你真的会换掉你的日志框架吗?嗯，也有很多人要么不提及包装，要么反对包装.如果您查看此处发布的一些日志框架包装代码示例，您还会看到许多示例，说明为什么至少有些人不应该包装他们的日志框架！

Obviously, this allows you to not be tied to a specific framework. Is this important? Will you ever really switch out your logging framework? Well, there are also plenty of people who either don't mention wrapping or those who recommend against it. If you look at some of the examples of logging framework wrapping code that has been posted here, you can also see many examples of why at least some people should not wrap their logging framework!

如果您最近开始了一个项目，您可能已经研究过日志框架，并且可能将其缩小到两个决赛选手:log4net 和 NLog.每个人都有对自己有利的论据.log4net 显然是一个最爱，可能是那些发表意见的人的最爱.NLog 提供了非常相似的功能.从受欢迎程度来看，log4net 可能是明智的选择.根据功能，它们看起来非常相似.基于最近的活动"(如通过博客活动签入他们的源代码存储库或缺乏或缺乏)，NLog 是明确的选择.如果您必须在一年前选择，您可能会选择 log4net，因为它是安全"的选择.目前尚不清楚 NLog 何时发布.从那以后的一年里，NLog 经历了一个相当重要的开发周期，几天前才发布了测试版.

If you had started a project recently, you might have examined logging frameworks and, perhaps, narrowed it down to two finalists: log4net and NLog. Each has arguments in its favor. log4net is clearly a favorite, probably THE favorite of those who have expressed an opinion. NLog provides very similar capabilities. Judged by popularity, log4net might be the clear choice. Based on capabilities, they seem very similar. Based on "recent activity" (as indicated by checkins to their source code repostories by blog activity or lack thereor), NLog be the clear choice. If you had to pick a year ago, you might go with log4net since it would be the "safe" choice. It was not clear when NLog would release. In the year since, NLog has gone through a pretty signifcant development cycle, releasing a beta version just a few days ago.

一年前选择哪个?现在选择哪个?那么，一个显然是更好的选择吗?现在是更好的选择吗?

Which to choose a year ago? Which to choose now? Was one a clearly better choice then? Is one the better choice now?

抽象给你带来的一件事是推迟决定选择哪一个的能力(你甚至不一定必须选择EVER，尽管如果你计划为你的产品提供日志框架，你可能想要).您可以先试驾一个，然后再试驾另一个，并了解它们在您的环境中如何与您的应用程序、您的团队一起工作.使用类似 Common.Logging 或 SLF 允许您现在开始编写代码、编写某些日志记录接口/API 并准备好您的日志记录代码.如果您认为抽象提供的接口/API 足以满足您的工作(而且，为什么不这样，因为它与 log4net 和 NLog 提供的接口/API 本质上相同)，那么没有太多使用抽象的危险.在您完成开发周期时，您可能会发现一个或另一个框架更适合您的需求.对抽象进行编码后，您可以在任何时候自由地做出选择，直到您的产品上市为止.

One thing an abstraction gets you is the ability to put off the decision of which one to choose (you don't necessarily even HAVE to choose EVER, although you probably want to if you plan to deliver the logging framework with your product). You can test drive one and then the other and get a feel for how they work with your application, with your team, in your environment. Using something like Common.Logging or SLF allows you start writing code now, coding to some logging interface/API, and getting your logging code in place. If you believe that the interface/API is provided by the abstraction is sufficient for your work (and, why wouldn't it be since it is essentially the same as the interface/API provided by log4net and NLog), then there is not much danger in using the abstraction. As you go through the development cycle, you might find that one framework or the other better suits your needs. Having coded to the abstraction, you are free to make that choice at any point, up until the time your product goes out the door.

您甚至可能在心里想，您可以从头开始编写日志库.同样，如果您认为 log4net 和/或 NLog 的接口/API 就足够了，您可以使用类似的 API 来实现您的日志记录库.如果您相信这一点，那可能是使用抽象的另一个原因.同样，您可以从今天开始编写代码(为您的产品，而不是您的日志库)，使用其他一些日志框架进行日志记录，直到您的从头开始"日志库准备就绪为止.也许您真的想使用 System.Diagnostics.TraceSource 和 Ukadc.Diagnostics(以获得类似于 log4net 的输出格式化功能或 NLog)，以便您可以更好地"与 Microsoft 使用 TraceSources 在其某些平台中实现的日志记录集成.根据 TraceSources 编写记录器"，然后编写抽象，以便您可以将其插入 Common.Logging 或 SLF 中，这可能非常容易.(如果接口/API 足够了，您可以根据抽象库的接口编写记录器"，而不必编写额外的抽象层).

You might even be thinking, in the back of your mind, that you could possibly write a logging library from scratch. Again, if you believe that the interface/API of log4net and/or NLog is sufficient, you might implement your logging library with a similar API. If you believe that, that might be another reason to use an abstraction. Again, you can start writing code (for your product, not your logging library) today, logging with some other logging framework until such time that your "from scratch" logging library is ready. Maybe you really want to use System.Diagnostics.TraceSource and Ukadc.Diagnostics (to get output formatting capabilities similar to log4net or NLog) so that you can get "better" integration with the logging that Microsoft has implemented in some of their platforms using TraceSources. It could be pretty easy to write a "logger" in terms of TraceSources and then write the abstraction so that you could plug it into Common.Logging or SLF. (If the interface/API is sufficient, you could just write your "logger" in terms of the abstraction library's interface and not have to write an additional abstraction layer).

有了这些有说服力的论据，为什么有人不使用抽象?哈哈，开个玩笑！

With such persuasive arguments as these, why would anyone ever NOT use an abstraction? Ha ha, just kidding!

如果抽象是好的，你应该自己写还是使用现有的?如果你自己写一个，那么你显然必须写它.如何做到这一点?好吧，您可能只定义一个接口并包装一个框架(小心并正确包装它！).稍后，如果您决定要切换，请包装该框架.如果您小心，您不必更改任何应用程序代码，除了您实际创建底层框架对象的地方.也许这很好.由于在单个框架上实现单个包装器的小"代价，您避免了对某些第三方抽象的依赖.但是，这是有代价的.在您编写抽象之前，您无法真正编写大量具有登录功能的应用程序代码，除非您有一个很好的策略将其更改为您的抽象.测试驱动两个或多个框架以确定哪个更适合您的框架也变得更加困难.您想要尝试"的每个框架都需要另一个包装作业.如果您想轻松地在框架之间切换(至少在开发周期中)，您需要做一些工作来使其变得容易.第三方框架提供了开箱即用的功能.

If an abstraction is good, should you write your own or use an existing one? If you write one on your own, then you obviously have to write it. How does one do this? Well, you might just define an interface and wrap one framework (be careful and wrap it correctly!). Later, if you decide you want to switch, wrap that framework. If you are careful, you don't have to change any application code, except for maybe the place where you actually create the underlying framework's objects. Maybe this is good. You have avoided a dependency on some third party abstraction for the "small" price of implementing a single wrapper over a single framework. However, there is a cost. Until you have written your abstraction you cannot really write a lot of application code that has logging in it, unless you have a good strategy for changing it over to your abstraction. It also becomes more difficult to test drive two or more frameworks to decide which works better for your. Each framework that you want to "try" requires another wrap job. If you want to switch among frameworks easily (at least during development cycle), you have work to do to make it easy. The third party frameworks provide this out of the box.

哇！现在我被卖了！给我日志抽象，或者给我死！

Wow! Now I'm sold! Give me logging abstraction, or give me death!

日志抽象都是肉汁吗?有什么缺点吗?他们不可能那么好，是吗?

Are logging abstractions all gravy? Is there a downside? They can't THAT great, can they?

嗯，一如既往，当购买"某物或免费获得某物时，您会得到可用的东西.日志抽象也没有什么不同.Common.Logging 和 SLF 都至少公开了 log4net/NLog 的一组非常重要的功能——日志上下文功能(GDC、MDC、NDC).这些可能是获取足够的信息记录和格式化的关键，使您能够从您的信息中获得最大价值.SLF 不提供 TraceSource 抽象.它也不提供 IsXXXEnabled 功能.Common.Logging 提供了一个 TraceSource 抽象.Castle.Logging 确实为 log4net 和 NLog 公开 GDC/MDC/NDC.它还提供了一个 TraceSource 抽象.Castle 的 TraceSource 抽象还通过提供类似于 log4net 和 NLog 提供的分层"命名功能来增强 TraceSource 日志记录.看起来很酷！

Well, as always, when "buying" something or when getting something free, you get what is available. Logging abstractions are no different. Neither Common.Logging nor SLF expose at least one very important set of capabilities of log4net/NLog - the logging context capabilities (GDC, MDC, NDC). These can be key to getting adequate information logged and formatted to enable you to get the most value from your. SLF does not provide a TraceSource abstraction. It also does not provide IsXXXEnabled functions. Common.Logging provides a TraceSource abstraction. Castle.Logging DOES expose GDC/MDC/NDC for log4net and NLog. It also provides a TraceSource abstraction. Castle's TraceSource abstraction also enhances TraceSource logging by providing a "hierarchical" naming capability, similar to that provided by log4net and NLog. It looks pretty cool!

此外，这些项目都是一种或另一种形式的开源.因此，根据抽象的不同，开发人员可能或多或少有兴趣使其保持最新和添加新功能.Common.Logging 已经经历了几个版本，并在 Spring.Net 中使用，AFAIK.至少在历史上似乎相当活跃.Castle.Logging 用于 Castle 框架.因此，他们显然拥有真实"的客户并且正在获得真实世界"的使用，这有望推动更多的功能实现.据我所知，SLF 没有被用作真正"开发平台的一部分，因此很难说它被执行了多少.

Also, these projects are all opensource of one form or another. So, depending on the abstraction, the developers might have more or less of a vested interest in keeping it up to date and adding new features. Common.Logging has been through a few versions and is used, AFAIK, in Spring.Net. Seems reasonbly active, at least historically. Castle.Logging is used in the Castle framework. So, they apparently have "real" customers and are getting "real world" usage, which will hopefully drive more feature implementation. SLF, as far as I can tell, is not used as part of a "real" development platform, so it is hard to tell how much it is exercised.

目前尚不清楚这些平台的路线图是什么.Common.Logging 在他们的网站上列出了一些即将推出的功能，但没有明确说明何时可用.网站上写着六月"，但哪一年?多久监控一次邮件列表?对于 SLF，他们的 Codeplex 多久监控一次?与开发商的付费工作相比，这些免费"项目的优先级在哪里?你能负担得起一些第三方抽象来实现你需要的功能吗?如果您实施某项内容然后将其提交回以考虑将其包含在产品中，他们会接受吗?

It is not clear what the roadmap is for these platforms. Common.Logging has some upcoming features listed on their website, but not clear indication when they will be available. The website says "June", but of what year? How often is the mailing list monitored? For SLF, how often is their codeplex monitored? Where does the priority of these "free" projects rate compared to the developers' paying jobs? Can you afford for some third party abstraction to implement a feature that you need? Will they be receptive if you implement something and then submit it back for consideration to be included in the product?

从好的方面来说，所有这些抽象的所有源都是可用的，因此您可以承担责任并进行任何修复或添加任何增强功能，而无需花费时间和精力进行创建从头开始的抽象.你喜欢 Common.Logging 但真的想要 log4net/NLog GDC/MDC/NDC 吗?获取 Castle 的实现并将其添加到 Common.Logging.瞧！包含近 100% 的 log4net/NLog 日志 API 的日志抽象.您是否更喜欢 SLF 但希望它具有 IsXXXEnabled?没有太多的工作来实现这一点.继续在 GDC/MDC/NDC 上进行操作.你喜欢城堡吗?(我不太熟悉它，不确定在 Castle 之外使用它有多容易，如果这很重要)小心，我没有使用它，但是在 git 上查看源代码，它看起来像 NLog 记录器抽象可能不会保留调用站点信息.

On the plus side, all of the source for all of these abstractions is available, so you could just assume responsibility for it and make any fixes or add any enhancements that you which, without having to go through time and energy of creating an abstraction from scratch. Do you like Common.Logging but really want log4net/NLog GDC/MDC/NDC? Get Castle's implementation and add it to Common.Logging. Voila! A logging abstraction that contains nearly 100% of the log4net/NLog logging API. Do you prefer SLF but wish it had IsXXXEnabled? Not much work to implement that. Go ahead and tack on the GDC/MDC/NDC while you are at it. Do you like Castle? (I'm not that familiar with it, not sure how easy it is to use outside of Castle, if that matters) Be careful, I haven't used it, but looking at the source on git, it looks like the NLog logger abstraction might not retain call site info.

参与多个开源项目并将它们组合成一个超级"项目(供您自己或您的公司使用)是否合乎道德?使用 Common.Logging 并用 Castle 的 GDC/MDC/NDC 实现对其进行扩充是不是很糟糕?我不知道.我会让其他人回答这个问题.

Is it ethical to take parts of multiple open source projects and combining them to make one "super" project (for your own or your company's use)? Is it bad to take Common.Logging and augment it with Castle's GDC/MDC/NDC implementation? I don't know. I'll let someone else answer that.

我快完成了...

一些第三方日志抽象提供了其他功能.您可能会使用根据 log4net 实现的库.您可能不想使用 log4net，或者至少可能不想绑定到它.Common.Logging(可能还有 SLF)使您可以相对容易地捕获 log4net 日志消息并通过抽象重新路由它们，以便在抽象的底层日志框架的日志流中捕获它们.SLF 可能会提供类似的东西.当然，您可以对现有的日志框架做一些类似的事情，可以是开箱即用的，也可以是编写自定义 log4net Appender、NLog Target 或 System.Diagnostics TraceListener.在我对是否在我的项目中使用第三方日志抽象的特定评估中，这些功能并没有特别高，因为我主要对抽象方面感兴趣.

Some third party logging abstractions provide other capabilities. You might use a library that is implemented in terms of, say log4net. You might not want to use log4net, or at least might not want to be tied to it. Common.Logging (and maybe SLF) makes it relatively easy for you to capture the log4net logging messages and reroute them through the abstraction so they are captured in the abstraction's underlying logging framework's logging stream. SLF might provide something similar. Of course, you might be able to do something similar with existing logging frameworks, either out of the box or by writing a custom log4net Appender, NLog Target, or System.Diagnostics TraceListener. These features have not bubbled up very high in my particular evaluation of whether or not to use a third party logging abstraction on my project because I am mainly interested simply in the abstraction aspect.

那么，我站在哪里?我认为将您的应用程序代码与特定日志框架隔离是有价值的.对我来说，Common.Logging 看起来像是一个可靠的抽象选择，尽管缺少一些重要的功能(GDC/MDC/NDC)并且它与 Silverlight 不兼容.如果这些功能很快可用，那就太好了.如果需要，我很乐意实施 GDC/MDC/NDC.使其与 Silverlight 兼容可能需要更多的努力，主要是因为我对 C#/.NET/Silverlight 不是特别有经验.在解决这些问题之前，我们将能够编写大量带有 Common.Logging 的应用程序代码.我们可以花时间开发我们的应用程序，而不是开发另一个日志库或抽象库.如果我们最终不得不自己添加那些缺失的功能，那么如果我们自己实现日志库或抽象库，我们将不得不做很多事情.

So, where do I stand? I think that there is value in keeping your application code insulated from a specific logging framework. To me, Common.Logging looks like a solid choice of abstraction, although some important features are missing (GDC/MDC/NDC) and it is not Silverlight compatible. It would great of those features became available soon. I am comfortable with implementing GDC/MDC/NDC if I have to. Making it Silverlight compatible would probably take more effort, primarily because I am not particularly experienced with C#/.NET/Silverlight. Until those issues are ironed out, we would be able to write plenty of application code with Common.Logging in place. We can spend our time developing our application rather than developing yet another logging library or abstraction library. If we end up having to add those missing features ourselves, well, we would have had to do a lot of that if we had implementing a logging library or abstraction library ourselves.

这篇关于伐木立面的意义何在?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！