评分 .NET 开源 AOP 框架

引言

在当今商业敏捷性成为任何企业/IT 基础设施的必然需求的日子里，我们经常会遇到需要开发灵活且易于管理的应用程序的场景。

应用程序架构的灵活性是新兴的商业竞争、应对创新商业模式带来的挑战的压力、维持成熟业务不断增长的客户群等因素所要求的。例如，您正在构建一个具有创新商业模式、面向细分市场的电子商务系统。很快，它在市场上变得炙手可热，您的系统在短时间内用户量急剧增长。系统开始缓慢，无法承受增加的用户负载，从而给您的业务以及您通过辛勤工作和创新所建立的良好声誉造成重大损失。

可能导致您的业务下滑的情况包括：

• 由于政府的法规/政策发生变化，您可能需要在系统运行时集成更多规则。
• 为了增加收入，需要将支付网关从一个切换到另一个提供折扣服务的网关。
• 需要从一家包装公司转移到另一家（例如从 FedEx 转移到 UPS），因为需要提高交货速度。
• 要求从某个特定的金融外包服务提供商转移到另一个。
• 等等。

能够在这种敏捷环境中表现出色的架构可以称为“可插拔架构”。有成熟的方法（模式）可以构成实现这种架构的设计。AOP 是市场上广泛采用的此类模式/方法之一。

背景

AOP – 面向方面编程（Aspect Oriented Programming）是一种将“横切关注点”与封装业务逻辑的代码块分离的方法。“横切”指的是非业务特定且在跨不同层分布的类中重复的代码块。横切关注点的示例包括：日志记录、代码检测特有的异常处理代码块等。可能有许多此类关注点需要从特定于业务逻辑的代码中抽象出来。

识别横切关注点的基本经验法则是：如果一个关注点在跨层/层分布的类中重复出现，那么它就是一个横切关注点。

AOP 的好处

分离横切关注点的功能有助于：

1. 根据需要选择性地应用横切关注点。例如，与代码性能监控相关的某些代码分析逻辑可能仅在测试期间需要，而在生产环境中不需要，因此可以根据需要启用/禁用它们。
2. 在不影响生产环境中的业务逻辑代码的情况下，对横切代码逻辑进行任何更改/修复错误。
3. 系统的不同部分以不同的速度进行演进。
4. 最终形成一个易于理解和维护的代码解决方案。

需要评分方法

在认识到 AOP 的好处后，下一步是寻找在我们的应用程序开发中实现它的方法。在这种情况下，与其从头开始，不如利用世界各地许多勤奋的技术达人通过开源框架/实用工具所做的研究和努力。

当我们处于选择采用开源 AOP 框架的阶段时，市场上有很多开源 AOP 框架可供选择，因此我们需要为我们的开发选择最佳的一个。选择最佳的可能是一项艰巨的任务，因为尤其是在团队中时，总会有思想冲突和意见分歧。特别是当我们必须说服客户采用某个特定框架时，除非有一些好的理由，否则我们不能选择某个 AOP 框架。

如果我们有一个评分方法，可以对可用的 AOP 框架进行定性和定量分析和评估，从而能够对市场上的 AOP 框架进行评分，以便我们在短时间内做出明智的决定，这样不是很好吗？这种思路的结果是以下“框架评分方法”。

开源 AOP 框架评分方法

作为这项工作的一部分，我确定了一些属性（可以扩展/改进），并为每个 AOP 框架分配了分数（这是主观的——它基于我的研究和可用的信息。您可以根据您的观察和判断进行更改。）

本次评分过程考虑的开源 AOP 框架列表是：

• Aspect#
• AspectDng
• NAspect
• PostSharp
• Policy Injection Application Block
• Sesar
• Spring.NET [Spring.AOP]

本次评分过程确定并使用的评分属性是：

采用的方法论的质量	有不同的方法可以实现 .NET 中的 AOP。每个可用的开源 AOP 框架都采用了不同的方法。基本上，AOP 可以通过编译时或运行时来实现。在我看来，运行时总是比编译时开销大，因为它是一次性过程。有关可用方法的详细信息，请访问：http://www.ayende.com/Blog/archive/2007/07/02/7-Approaches-for-AOP-in-.Net.aspx 当我调查这些开源框架所采用的方法的细节时，只有一些框架的信息清晰。我根据我的思路和看法分配了分数。它可能因人而异，取决于信息的可用性和研究的深度。
社区支持	当我们为开发项目选择某个开源框架时，除非有广泛的社区支持，否则我们无法使用它，因为它在部署过程中或在生产支持的后期阶段可能会存在高风险。
任何实现的可见性/行业范围内的采用	同样，在为解决方案确定最终架构时，我们的客户可能会寻找我们选择的产品已被验证的案例研究/行业范围内的采用。同样的情况也适用于此处。有经过验证的案例研究的可用性将为我们提供对该框架的信心，特别是在我们进行大规模、企业级解决方案开发时。在此调查过程中，我很少看到列出的任何框架的经过验证的案例研究。
开发人员采用的简易性	这同样是主观的，并且因人而异。
所需的学习曲线	这同样是主观的，并且因人而异。
内存占用/开销	这可能是评价特定框架的关键属性。只有一些框架组明确了其产品的内存占用。由于这可能是影响性能和资源消耗的重要因素，尤其是在大规模部署中，因此我建议相应的框架提供商发布基准案例研究/实验室结果，这将为我们提供对该框架的信心。
市场上的可用版本（是 RC 还是仍在 Alpha 阶段？)/文档	一些框架仍处于早期开发阶段。框架后续版本的定期发布表明其积极的开发以及背后社区的热情。此外，文档（API、概念和架构）的可用性对于任何框架来说都是清晰理解它们的必要条件。

如果信息不清楚、不可用或含糊不清，我分配了非常低的分数。

评分属性指南

• 0 – 差，未知，不清楚，信息不足
• 1 – 有待改进，有一些信息可用
• 2 – 好，信息充足
• 3 – 很好，没有重大开销，没有重大内存占用，信息非常丰富

这是最终的评分矩阵

初步评分矩阵
可用的开源 .NET AOP 框架/实用工具
	NAspect – Puzzle。 Net	Aspect#	Policy Injection Appli- cation Block	PostSharp	Seasar	方面 Dng	Spring.Net
采用的方法论的质量	2	2	2	3	2	2	2
社区支持	2	2	3	3	1	1	3
任何实现的可见性/行业范围内的采用	1	0	2	2	0	0	1
开发人员采用的简易性	2	1	2	3	2	1	2
所需的学习曲线	1	1	2	3	1	1	2
内存占用/开销	1	0	1	3	0	0	1
市场上的可用版本（是 RC 还是仍在 Alpha 阶段？)/文档	2	2	3	3	2	1	3
总计	11	8	15	20	8	6	14

结论

每当我们实现 AOP 这样的特定方法论或概念时，我们总是会利用现有的开源框架。由于市场上存在许多开源框架，因此最好有一些具体的理由作为选择特定框架采用的基础。

采用本文所述的评分过程将确保框架经过定性和定量评估过程，从而做出有意义的决定。

从矩阵来看，“前三名”列表中的框架是：

• PostSharp
• Policy Injection Application Block
• Spring.Net [Spring.AOP]