设计应用程序范围的日志系统有哪些指导原则？

Question

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

现在让我们说我们有三层:

1. 表达层
2. 业务层
3. 数据访问层

并假设只有更高级别的层知道下面一层的层.例如,表示层知道业务层,但不是相反.

你应该在哪里实现一般记录器类？

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

实施日志记录机制的好地方是什么？

在实施之后,使用这样一个系统的方法是什么？

1. 理想情况下,它应该能够捕获未捕获的异常并在某处保存异常描述.
2. 你应该在哪里捕获例外？它们应该被捕获在最高层(表示层)吗？或者他们应该被别人抓到？
3. 用于将记录器传递给类的方法是什么？将方法/构造函数重载添加到接受类似接口的项目中的所有内容是否有意义ILogger？

正如您所看到的,我对这个主题非常困惑,在我目前的工作中,没有人对企业应用程序设计/分层设计有任何了解,即使他们正在设计企业应用程序.所以任何帮助向我展示正确的方向将不胜感激.

Answer 1

记录是一个贯穿各领域的问题.这意味着它包含您的体系结构的所有层,并且将其实现为单独的库是有意义的.然而,这只是一个练习,因为已经有很好的解决方案,如Log4Net,NLog,甚至.NET自己的TraceSources.

我更倾向于那些支持分层日志记录的东西(例如log4net).这使得在生产系统中配置所需的跟踪级别变得更加容易.例如,你可以设置一般跟踪级别MyApp.SomeNamespace到Warning,但还设置了一个特定类型的像MyApp.SomeNamespace.AnInterestingClass到Debug.

我不确定我是否理解"使用这种系统是什么方法"的一部分.

您可以在应用程序的所有层中,在需要它的每个方法中的任何位置使用日志记录.我的印象是你有一个集中的地方,处理和记录所有错误,但这些都是分开的.

理想情况下,它应该能够捕获未捕获的异常并在某处保存异常描述.

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

你应该在哪里捕获例外？

在各个层面.代码中的许多方法都将处理与当前上下文相关的异常.我想你真的想知道在哪里处理其他地方没有发现的异常 - 某种全能的处理程序.为此,通常在最顶层(即.exe中)或更常见地在包含表示应用程序本身的类型的层中执行此操作是有意义的.有很多方法可以做到这一点 - 从简单地将未处理异常(ThreadException/UnhandledException)的处理程序注册到ASP.NET MVC中的HandleError/Application_Error到使用异常处理应用程序块之类的东西,我个人不喜欢(因为大多数企业库) ).

用于将记录器传递给类的方法是什么？将方法/构造函数重载添加到项目中接受ILogger之类接口的所有内容是否有意义？

这取决于您的实施.您似乎想要沿着依赖注入路径走下去.由于logger不是必需的依赖项(即它与类型的函数行为无关,而是与实现有关),我宁愿通过属性注入作为可选依赖项来处理它,而不是通过IMO应该通过构造函数来实现它.仅用于主要依赖项 - 类型正常运行所需的依赖项.

但是,您可能不想使用DI.然后你需要一些其他方式来获取记录器.这里讨论一个选项.