我正在学习分层架构，我想知道如何在这样的设计中添加日志系统。
现在让我们说我们有三层：
并假设只有更高级别的层知道下面一层的层。例如，表示层知道业务层，但不是相反。
您应该在哪里实施常规记录器类？
实施日志记录机制的好地方是什么？
在实施之后，使用这样一个系统的方法是什么？
ILogger之类的接口的所有内容是否有意义？正如您所看到的，我对这个主题非常困惑，在我目前的工作中，没有人对企业应用程序设计/分层设计有任何了解，即使他们正在设计企业应用程序。因此，任何向我展示正确方向的帮助都将受到赞赏。
答案 0 :(得分：8)
记录是一个贯穿各领域的问题。这意味着它包含您的体系结构的所有层，并且将其实现为单独的库是有意义的。但是，这只是一个练习，因为已经有很好的解决方案，如Log4Net，NLog，甚至.NET自己的TraceSources。
我倾向于选择支持分层日志记录的那些（例如log4net）。这使得在生产系统中配置所需的跟踪级别变得更加容易。例如。您可以将MyApp.SomeNamespace的常规跟踪级别设置为Warning，但也可以将MyApp.SomeNamespace.AnInterestingClass设置为Debug。
我不确定我是否理解“使用这种系统的方法是什么”部分。
您可以在需要的每个方法中，在应用的所有图层中的任何位置使用日志记录。我的印象是你有一个集中的地方，处理和记录所有错误，但这些都是分开的。
理想情况下，它应该能够捕获未捕获的异常并保存 某处的异常描述。
不，不应该。记录器将东西写入日志，它们不处理异常。记录不仅用于报告错误。您还需要记录应用程序的执行情况和许多内部信息（但具有不同的跟踪级别），以便在生产或事后分析中对系统进行故障排除。
你应该在哪里捕获例外？
在各个层面。代码中的许多方法都将处理与当前上下文相关的异常。我想你真的想知道在哪里处理其他地方没有发现的异常 - 某种全能的处理程序。为此，通常在最顶层（即.exe中）或更常见地在包含表示应用程序本身的类型的层中进行此操作是有意义的。有很多方法可以做到这一点 - 从简单地将处理程序注册到未处理的异常（ThreadException/UnhandledException）到HandleError/Application_Error in ASP.NET MVC到使用exception handling application block之类的东西，我个人不喜欢（就像大多数企业库一样） ）。
用于将记录器传递给类的方法是什么？将方法/构造函数重载添加到接受像ILogger这样的接口的项目中的所有内容是否有意义？
这取决于您的实施。您似乎想要沿着依赖注入路径走下去。由于logger不是必需的依赖项（即它与类型的函数行为无关，而是与实现有关），我宁愿通过属性注入作为可选依赖项处理它，而不是通过构造函数来实现它，IMO应该仅用于主要依赖项 - 类型正常运行所需的依赖项。
但是，您可能不想使用DI。然后你需要一些其他方式来获取记录器。讨论了一个选项here。