横向关注的例子

什么是 cross-cutting concern的一个好例子? 在我看来,维基百科页上的医疗记录不完整。

从这个例子来看,为什么日志会导致代码复制(散射) ?(除了像 log("....")这样到处都是的简单调用之外,这似乎没什么大不了的)。

core concerncross-cutting concern的区别是什么?

我的最终目标是更好地理解 AOP。

86289 次浏览

我认为横切关注点最好的例子就是交易行为。例如,在所有服务方法中都必须放置带有提交和回滚调用的 try-catch 块,这将是令人讨厌的。用标记注释这些方法,AOP 可以使用这些标记将它们封装为所需的事务行为,这是一个巨大的胜利。

另一个很好的例子是授权横切关注点。使用标记注释服务方法,告诉谁可以调用它,并让一些 AOP 建议决定是否允许方法调用,这比在服务方法代码中处理更可取。

使用 AOP 通知实现日志记录可能是获得更大灵活性的一种方法,这样您就可以通过更改连接点来更改日志记录内容。在实践中,我并不经常看到这样的项目。通常使用类似 log4j 的库,允许您在运行时根据日志级别和类别进行过滤(如果需要的话) ,这样就足够好了。

核心问题是应用程序存在的原因,即应用程序自动化的业务逻辑。如果你有一个物流应用程序,处理货运,搞清楚有多少货物,你可以包装在卡车或什么是最好的路线让卡车下降其交付可能是核心问题。横切关注点通常是需要与业务逻辑分开的实现细节。

除了公认的答案之外,我还想提到另一个横切关注点的例子: 远程处理。假设我只是想在本地调用生态系统中的其他组件,就好像它们在进程中运行一样。也许在某些情况下,他们甚至这样做。但是现在我想在云或集群中运行分布式服务。作为一个应用程序开发人员,我为什么要关心这个方面呢?一个方面可以负责找出要呼叫谁以及如何呼叫,必要时序列化传输的数据并进行远程呼叫。如果所有内容都在进程中运行,方面将只转发本地调用。在被调用方面,方面将反序列化数据,进行本地调用并返回结果。

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

我可以对其他交叉问题提出类似的解释。保持代码清洁和免于分散和纠缠 IMO 是一个专业性的问题,而不是任何可选的。最后但并非最不重要的是,它保持了代码的可读性、可维护性和可重构性。阿门。

在了解 横切关注之前,我们必须先了解 担心

担心是一个术语,指的是根据功能划分的系统部分。

有两种担忧:

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

礼貌

enter image description here

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

(礼貌)

不论申请类型如何,应始终注意的问题是各种情况。

例如日志记录、安全性、性能分析、本地化、可访问性、事务等。 不管我们正在构建的软件是否需要日志记录(否则有些人将如何调试或从产品数据中获得一些相关信息)。需要安全性(身份验证/授权等)的情况下,只有真实的用户可以进入具有正确权限的应用程序。我们需要知道您的应用程序如何执行,然后我们需要进行分析。 如果应用程序被国际用户使用(使用他们自己的本地化语言) ,那么我们需要在应用程序中支持相同的语言。 易访问性是残疾人使用我们的应用程序的可用性案例。

现在不管我们的应用程序是否是基于桌面,网络等,如果它需要使用的最终用户跨地域的生产环境,然后横切是必要的。 到目前为止,我还没有说过应用程序是什么等等,但是给出了在生产环境中向最终用户发布应用程序之前应该解决的问题列表。这些都是关于横切关注点(需要由不同级别的所有应用程序/方法/类处理)。

我从维基百科上清楚地看到:

如果编写一个处理医疗记录的应用程序,这些记录的索引是一个核心问题,而记录对记录数据库或用户数据库或认证系统的更改历史将是跨领域的问题,因为它们与程序的更多部分相互作用。

往往涉及各领域的关切事项包括:

商业规则

缓存

代码移动性

数据验证

特定于域的优化

纠错

国际化与本地化,包括语文 本地化

资讯保安

伐木

内存管理

监察

坚持不懈

产品特性

实时约束

同步

交易处理

上下文敏感的帮助