2

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

现在假设我们有三层：

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

并假设只有更高级别的层知道下面的一层。例如，表示层知道业务层，但反之则不然。

你应该在哪里实现一个通用的记录器类？

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

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

而在实施之后，有什么方法可以使用这样的系统呢？

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

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

4

1 回答 1

8

日志记录是一个跨领域的关注点。这意味着它包含架构的所有层，并且将其作为一个单独的库来实现是有意义的。但是，这仅作为练习才有意义，因为已经有非常好的解决方案，例如 Log4Net、NLog，甚至 .NET 自己的 TraceSources。

我更喜欢那些支持分层日志的（例如 log4net）。这使得在生产系统中配置所需的跟踪级别变得更加容易。MyApp.SomeNamespace例如，您可以为to设置一般跟踪级别Warning，但也可以设置特定类型，例如MyApp.SomeNamespace.AnInterestingClassto Debug。

我不确定我是否理解“使用这种系统的方法是什么”部分。

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

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

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

你应该在哪里捕获异常？

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

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

这取决于您的实施。看来您想沿着依赖注入路径走下去。由于 logger 不是基本依赖项（即它与类型的功能行为无关，而是与实现有关），我更愿意通过属性注入作为可选依赖项来处理它，而不是通过 IMO 应该的构造函数来处理它仅用于主要依赖项 - 类型正常运行所需的依赖项。

但是，您可能不想使用 DI。然后你需要一些其他的方法来获取记录器。这里讨论一种选择。

于 2013-04-13T23:18:23.593 回答