标签：进程 xxx 性能 运行 方法 try 解决 三层 影响
软件开发中Logging无疑是非常重要的，在开发环境中遇到问题我们可以用源代码调试，但在测试和生产环境中就没那么好了，一般的做法是利用Log去查找问题所在，然后分析原因和想出解决方案。所以在程序中Logging是很有用的，也是很有必要的。
但是我们应该在什么时候、什么地方Logging好呢？网上好像没看到有人谈这个问题，在此我想谈谈我个人对这个问题的看法。
传统的三层架构由底往上分别是：数据访问层、业务逻辑层、用户界面层或服务层。那么我们是不是应该在每一层都Logging呢？在我们公司里确实这样，在每一层都可以Logging的身影。但在我看来这样做并不好，原因主要有：
1、不利于分离关注点
既然分了层，各层就应该各司其职，集中做本层应该做的事情，而不要去做与本层职责不相关的事情，如业务层就应该集中在业务逻辑的处理上，而数据访问层则集中在数据的读写上。
2、不利于单元测试
在业务逻辑层Logging也不利于单元测试。我们都知道单元测试的时候应该只针对单个类进行，而把依赖的类Mock up。如果在业务层Logging，那么业务类就会依赖于Logging组件，这样就不利于单元测试。虽然我们可以把Logging方法抽象一下，让业务类只依赖于Logging的接口，这样单元测试的时候可以Mock up掉Logging方法，但还是比较麻烦。
3、容易导致重复写Log
我们通常是在底层Logging了，出于让上层知道下边出了问题的目的，我们还是继续往上层抛异常，而上层往往又会去Logging，这样一来就重复写Log了。
4、对性能有较大的负面影响
上一条所说的重复写Log无疑对系统的性能有负面影响。另外为了Logging，我们通常用Try Catch块把相关代码包起来，当捕捉到异常的时候才写Log。众所周知处理异常是有比较大的成本开销的，所以在底层重复Try Catch肯定会降低系统性能。
所以我的观点是Logging应该统一到进程的顶层做会比较好。所谓进程的顶层就是程序运行时最顶层的那部分代码，比如一个有UI的进程，那么就是在UI层；如果是一个服务的话，进程的顶层则是服务的壳层，如Web API层。这样做的好处是统一处理Logging，让底层代码做更纯粹的事情，不大会出现重复写Log的情况，另外这样写出来的Exception Log可以把整个错误堆栈包含进来，更加完整，更利于分析。
当然有些情况下在底层写些Log可能有比较强的理由，比如在数据访问层要调用第三方服务的情况。此时在数据访问层用Try Catch把调用第三方类的代码包进来，当异常发生的时候写Log。但我的看法是此种情况也不要直接在底层写Log，而是在捕捉到异常的时候往上层抛出一个自定义的异常，如FailedToAccessXXXServiceException，等到异常去到顶层的时候才统一写Log。
以上就是本人对Logging的一些看法，不一定对，欢迎拍砖。
标签：进程 xxx 性能 运行 方法 try 解决 三层 影响
原文地址：http://www.cnblogs.com/michaelsoft/p/logging.html
