C# 日志问题
有人知道有什么方法可以更方便地组织日志记录吗？
我想没有这样的方法，但是，好吧，这是一个小例子：
// Take the longest path in the graph and convert it into the
// image series, note that we project every element from the
// sequence into the image path so that 'new Series(...)' constructor
// could be used.
var paths = EnumerateSimpleAndLoopedPaths().ToList();
logger.Log(Something1);
if (paths.Any())
{
// Take the longest possible path.
var selectedPath = paths.OrderBy(x => x.Count()).Last();
logger.Log(Something2);
var imagesForSelectedPath = selectedPath.SelectMany(...
显然那些 logger.Log 或 Log 或任何语句对于主代码来说就像垃圾部分，也许有一种聪明的方法将它们带到某个地方？
我知道有一些不错的软件包，例如PostSharp，它允许在之前和之后完成日志记录 - 但是什么如果函数必须记录其某些中间结果工作？
或者这只是一个分解问题，我应该使所有内容更加分解，以便我可以将所有这些可记录条目标记为 [Loggable]？
任何建议将不胜感激。 您如何登录代码？
Does someone know any way to organize the logging statements more conveniently?
I guess there is no such way, but, well, here is a small example:
// Take the longest path in the graph and convert it into the
// image series, note that we project every element from the
// sequence into the image path so that 'new Series(...)' constructor
// could be used.
var paths = EnumerateSimpleAndLoopedPaths().ToList();
logger.Log(Something1);
if (paths.Any())
{
// Take the longest possible path.
var selectedPath = paths.OrderBy(x => x.Count()).Last();
logger.Log(Something2);
var imagesForSelectedPath = selectedPath.SelectMany(...
Obviously those logger.Log or Log or whatever statements are just like rubbish for the main code part, maybe there is a smart way to take them somewhere?
I know there are some nice packages, like PostSharp, which allows logging to be done before and after - but what if functions have to log some intermediate result of their work?
Or is this just a decomposition problem and I should make everything more decomposed so that I could mark all those loggable entries as [Loggable]?
Any suggestions would be appreciated. What do you do with logging in your code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如何将方法的内部逻辑划分为额外的私有方法来完成中间工作，
或者，如果您不想最终在类上出现太多只能在一个地方使用的方法，...
定义一个内部类来完成这项工作（如果将对父类的引用传递给内部类的构造函数，它会自动访问父类的私有成员）。
内部类可以有许多私有方法，这些方法只能由内部类上的方法访问。因此，在内部类上定义一个公共/内部方法，由外部类上的方法调用。
使用这两种方法，您可以使用 AOP 的属性来装饰新方法（例如 PostSharp）。
How about divided the inner logic of method to additional private methods to do the intermediate work,
or, if you don't want to end up with too many methods on class that can only be used in one place, ...
define an inner class to do the work (which automatically can access private members of parent class, if you pass reference to parent to inner class's constructor).
The inner class can have many private methods that can be accessed only by methods on the inner class. So define one public/internal method on inner class, to be called by method on outer class.
With both approaches, you can decorate new methods with attributes for AOP (e.g. PostSharp).
由于 AOP 框架的限制，您需要使用分解来全面获得好处。无论如何你都应该这样做。方法应该保持非常简单并且只做一件事。将条件逻辑提取到方法中，然后创建 PostSharp 方面。
我这样说是因为如果您需要在您的条件内进行日志记录，那么该代码块就足够重要，可以在它自己的方法中使用。除非您只是出于追踪原因而这样做，在这种情况下您可以做任何事情，因为无论如何它都应该是暂时的。
Due to the limitations of AOP frameworks, you'll need to use decomposition to get the benefit all the way around. You should be doing this anyway. Methods should be kept very simple and only do one thing. Extract out your conditional logic into a method(s) then create a PostSharp aspect.
I say this because if you need logging within your conditions then that block of code is significant enough to be in it's own method. Unless you're just doing it for tracing reasons in which case you can do whatever since it should be temporary anyway.