交叉关注的例子

Question

什么是一个很好的例子cross-cutting concern？维基百科页面上的医疗记录示例对我来说似乎不完整.

特别是从这个例子中,为什么日志记录会导致代码重复(散射)？(除了简单的呼叫,如log("....")无处不在,这似乎不是什么大不了的事).

a core concern和a有cross-cutting concern什么区别？

我的最终目标是更好地了解AOP.

Answer 1

在了解横切关注点之前,我们必须了解关注点.

甲关注的是,是指系统的功能的基础上划分的一部分的术语.

关注点有两种:

1. 表示主要要求的单一和特定功能的问题被称为核心问题.
   或
   系统的主要功能被视为核心问题.
   例如:业务逻辑
2. 代表次要要求功能的问题被称为横切关注点或系统范围的关注点.
   OR
   的横切关注点是关注它适用于整个应用程序,它会影响整个应用程序.
   例如:日志记录,安全性和数据传输是应用程序几乎每个模块都需要的问题,因此它们是跨领域的问题.

礼貌

此图表示分解为模块的典型应用程序.每个模块的主要关注点是为其特定域提供服务.但是,这些模块中的每一个还需要类似的辅助功能,例如安全日志记录和事务管理.横切关注点的一个示例是"日志记录",它经常用于分布式应用程序,以通过跟踪方法调用来帮助调试.假设我们在每个函数体的开头和结尾都进行日志记录.这将导致横切所有具有至少一个函数的类.

(礼貌)

Answer 2

我认为跨领域关注的唯一最好的例子是交易行为.例如,必须在所有服务方法中放置带有提交和回滚调用的try-catch块.使用AOP可用于使用所需事务行为封装它们的标记来注释方法是一个巨大的胜利.

作为跨领域关注的一个例子,另一个好的候选人是授权.使用标记来指示服务方法,该标记告诉谁可以调用它,并让一些AOP建议决定是否允许方法调用,可以优于在服务方法代码中处理它.

使用AOP建议实现日志记录可以提高灵活性,以便您可以通过更改连接点来更改记录的内容.在实践中,我看不到项目经常这样做.通常使用像log4j这样的库,它允许您根据日志记录级别和类别进行过滤,如果需要,可以在运行时运行得很好.

核心问题是应用程序存在的原因,即应用程序自动化的业务逻辑.如果您有一个物流应用程序来处理运输货物,那么计算出您可以在卡车上装载多少货物,或者卡车运送货物的最佳路线可能是核心问题.横切关注点通常是需要与业务逻辑分开的实现细节.

Answer 3

除了公认的答案之外,我想提一个跨领域问题的另一个例子:远程处理.假设我只是想在本地生态系统中调用其他组件,就像它们正在运行一样.也许在某些情况下他们甚至可以.但现在我想运行分布在云或集群中的服务.作为应用程序开发人员,我为什么要关心这方面？一个方面可以负责找出谁打电话,以及如何在必要时串行传输数据并进行远程呼叫.如果一切都在进行中,则方面只会转发本地呼叫.在被叫方方面,方面将反序列化数据,进行本地调用并返回结果.

现在让我告诉你一个关于日志输出等"琐碎"事情的小故事:就在几周前,我为客户重构了一个复杂但不太大的代码库(大约250K行代码).在几百个类中,使用了一种日志框架,另外还有几百种.然后有几千行System.out.println(*)真正应该有日志输出的地方.所以我最终修复了遍布代码库的数千行代码.幸运的是,我可以在IntelliJ IDEA中使用一些聪明的技巧(结构搜索和替换)以加快整个动作,但是男孩不认为这是微不足道的!当然,强烈依赖于上下文的调试日志记录将始终发生在方法体中,但是许多重要类型的日志记录(例如跟踪方法调用(甚至是具有良好缩进输出的分层结构),记录处理或未处理的异常,用户审核(记录调用到基于用户角色的限制方法等等可以在不污染源代码的方面轻松实现.日常应用程序开发人员不需要考虑它,甚至不会看到分散在代码库中的记录器调用.有人负责使方面保持最新,甚至可以在一个地方集中切换日志记录策略或整个日志记录框架.

我可以针对其他跨领域问题提出类似的解释.保持代码清洁,免受散射和纠缠IMO是一个专业的问题,而不是任何可选的.最后但并非最不重要的是,它使代码可读,可维护,可重构.阿门.