设计应用程序范围的日志系统的指导原则是什么?

本文关键字：原则 是什么 日志 应用程序 范围 系统 | 更新日期: 2023-09-27 18:09:02

我现在正在学习分层架构，我想知道如何在这样的设计中添加日志系统。

现在假设我们有三个图层:

    表示层
  1. 业务层
  3. 数据访问层

并假设只有更高层的层知道下一层。例如，表示层知道业务层，但业务层不知道表示层。

应该在哪里实现一个通用的日志记录器类?

  1. 如果我在不同的项目中实现它，这意味着所有的层都依赖于一个共同的程序集，这可能是或可能不是好的。虽然这可以通过依赖注入来克服。
  2. 如果我在最高层(在我们的例子中是表示层)实现它，它将违背单一责任原则。

什么是实现日志机制的好地方?

在实现之后，如何使用这样一个系统?

  1. 理想情况下，它应该能够捕获未捕获的异常并将异常描述保存在某个地方。
  2. 应该在哪里捕获异常?它们应该在最高的层(表示层)中捕获吗?或者他们应该在别的地方被抓?
  3. 和什么方式是用来传递一个记录器到一个类?在项目中添加一个方法/构造函数重载来接受像ILogger这样的接口是否有意义?

正如你所看到的，我对这个主题很困惑，在我目前的工作中，没有人对企业应用程序设计/分层设计有任何了解，即使他们正在设计企业应用程序。因此，任何帮助告诉我正确的方向将不胜感激。

设计应用程序范围的日志系统的指导原则是什么?

日志记录是一个横切关注点。这意味着它包含了体系结构的所有层，并且将其实现为一个单独的库是有意义的。然而，这只能作为一种练习，因为已经有非常好的解决方案，如Log4Net, NLog，甚至。net自己的tracesource。

我倾向于那些支持分层日志记录的(例如log4net)。这使得在生产系统中配置所需的跟踪级别更加容易。例如，您可以将MyApp.SomeNamespace的一般跟踪级别设置为Warning，但也可以设置特定类型，如MyApp.SomeNamespace.AnInterestingClass到Debug。

我不确定我是否理解了"如何使用这样一个系统"的部分。

你在任何需要的地方使用日志记录，在你的应用程序的所有层，在每个需要它的方法中。在我的印象中，您有一个集中处理和记录所有错误的地方的想法，但这些是分开的事情。

理想情况下应该能够捕获未捕获的异常并保存

不，它不应该。记录器将内容写入日志，它们不处理异常。日志记录不仅用于报告错误。您还需要记录应用程序的执行和许多内部信息(但是使用不同的跟踪级别)，以便在生产中对系统进行故障排除或事后分析。

应该在哪里捕获异常?

在所有级别。代码中的许多方法将处理与当前上下文相关的异常。我猜想您确实想知道在哪里处理在其他地方没有捕获到的异常——某种全能处理程序。为此，通常在最顶层(即在.exe中)或者更一般地说，在包含代表应用程序本身的类型的层中这样做是有意义的。有很多方法可以做到这一点——从简单地为未处理的异常(ThreadException/UnhandledException)注册处理程序到ASP中的HandleError/Application_Error。. NET MVC到使用像异常处理应用程序块这样的东西，这是我个人不喜欢的(和大多数企业库一样)。

用什么方法来传递一个记录器到一个类?将方法/构造函数重载添加到项目中接受像ILogger这样的接口的所有内容中是否有意义?

这取决于你的实现。看起来您想要沿着依赖注入的路径走下去。由于logger不是基本依赖项(即它与类型的功能行为无关，而是与实现无关)，我宁愿通过属性注入作为可选依赖项来处理它，而不是通过构造函数来处理它，在我看来，构造函数应该只用于主要依赖项-那些类型正常工作所必需的依赖项。

但是，您可能不想使用DI。那么您需要其他方式访问logger。这里讨论了一个选项

相关文章：