我正在开始这个新项目，我们正在研究我们的日志记录/调试方法，我想向你们其他人提出这个问题，因为
private final static Logger logger = LoggerFactory.getLogger(getClass());
...
public void doSumething(){
...
if(logger.isDebugEnabled())
logger.debug("...");
}
或
@After("execution(* *.doSomething())")
public void logAfter(JoinPoint jp){
logger.debug("...");
}
AOP 方法真的比使用传统方法更好吗？还是 AOP 在日志记录/分析的特定用例中表现出色？
【问题讨论】：
就性能而言，AOP 方法肯定比传统方法有一点开销。
AOP 的众多优势之一是它允许您将非业务关注点与业务逻辑分开。它还可以帮助您完成日常任务，例如在每个方法中添加日志记录逻辑，或在每个方法中添加 try-catch 语句。
我认为真正的问题是，如果性能开销（根据我的经验，这只是最小的）可以补偿您在开发时必须完成的平凡任务。
一位朋友之前告诉我，最好拥有一个可维护和可扩展的较慢应用程序，而不是拥有一个速度较快的应用程序，让您在维护方面陷入困境。速度慢可以通过多种方式得到补偿，例如升级硬件等。
这只是我的两分钱，希望对您有所帮助。
【讨论】：
我不认为这些应该被视为相互排斥的选择。
我认为 AOP 非常适合跟踪（即记录方法进入/退出和参数值）。
我仍然使用常规日志记录：
【讨论】：
我很喜欢面向方面的方法。将日志记录与逻辑分开感觉是对的。不过，我不确定性能开销。
即使您决定不使用 AOP，也有比这更好的日志记录方法：
if(logger.isDebugEnabled())
看看 log4j，它可以让你改变日志级别、不同的 appender 和很多其他的东西。
【讨论】：
我同意@daxsorbito 的回答 - 并希望以此为基础。
可以使用配置文件配置横切建议，这样您就可以为生产日志记录提供不同的 aop 建议。这可以提高性能。
AOP 可以减少大量代码混乱并鼓励开发人员专注于主要任务。
如果代码有足够的日志记录，很多调试会变得更容易。 AOP 使其独立于开发人员。一些开发人员可能没有遵循足够的日志记录规则。或者可能觉得没有必要。
日志文件有一致的消息。 （不再是“你说土豆，我说 batata... :)”） - 每个开发人员可能会以不同的方式记录它。但是，如果我们对其进行 AOP-fy，您可以使其在整个应用程序中保持一致，并轻松地在其之上放置很多好的分析。
这也鼓励您编写易于调试的小型可重用（如果有时可测试，则更好）方法。
有时，这也会鼓励您遵循一致的命名约定，因为这样可以更轻松地在调试期间应用建议来记录这些方法。
【讨论】：