AspectF（Fluent Aspect Framework）是不是一种类似AOP的设计，可以不用太担心呢？

Question

Omar Al Zabir 正在寻找“一种更简单的 AOP 风格编码方法”。

他创建了一个名为 AspectF 的框架，这是“一种将方面添加到您的代码”。

这不是真正的 AOP，因为它不做任何编译时或运行时编织，但它是否实现了与 AOP 相同的目标？

以下是 AspectF 用法的示例：

    public void InsertCustomerTheEasyWay(string firstName, string lastName, int age,
        Dictionary<string, string> attributes)
    {
        AspectF.Define
            .Log(Logger.Writer, "Inserting customer the easy way")
            .HowLong(Logger.Writer, "Starting customer insert", "Inserted customer in {1} seconds")
            .Retry()
            .Do(() =>
                {
                    CustomerData data = new CustomerData();
                    data.Insert(firstName, lastName, age, attributes);
                });
    }

以下是作者的一些帖子，进一步阐明了 AspectF 的目标：

• AspectF 流畅的方式将方面放入代码中以实现关注点分离（博客)
• AspectF （谷歌代码）
• AspectF 流畅地添加方面以实现更简洁的可维护代码 (CodeProject)

根据作者的说法，我认为 AspectF 的设计并不像AOP 的替代品，而是一种实现“关注点分离并保持代码整洁”的方法。

一些想法/问题：

• 随着项目的发展，对使用这种编码风格有什么想法吗？
• 它是一个可扩展的架构吗？
• 性能问题？
• 可维护性与真正的 AOP 解决方案相比如何？

Answer 1

我并不是要抨击这个项目，但是
恕我直言，这是滥用 AOP。方面并不适合所有情况，这样使用只会妨碍可读性。

此外，我认为这错过了 AOP 的要点之一，即能够在不触及底层代码的情况下添加/删除/重新定义方面。

方面应该在受影响的代码之外定义，以使它们真正横切关注点。在 AspectF 的情况下，这些方面嵌入在受影响的代码中，这违反了SoC< /a>/SRP。

在性能方面，没有任何损失（或者可以忽略不计），因为没有运行时 IL 操作，正如代码项目文章中所解释的那样。然而，我在使用 Castle DynamicProxy 时从未遇到过任何性能问题。

Answer 2

在最近的一个项目中，有人建议我尝试一下 AspectF。
我牢记这样的想法：把所有的关注点都放在前面，让代码幸福地完成真正的工作，而不需要意识到它之外发生的所有检查和平衡。

实际上，我更进一步，添加了一个安全“问题”，即需要作为 WCF 请求的一部分接收的凭据。它进入数据库并执行其必须执行的操作。在运行返回所需数据的实际代码之前，我进行了明显的验证和安全检查。

我发现这种方法相当令人耳目一新，而且我当然喜欢在调试和测试服务调用时可以浏览 AspectF 的源代码。

在办公室里，一些人认为这些问题应该作为类/方法的装饰来实现。但你在哪里装饰它并不重要，在某个地方的某个时刻，你需要说你希望执行某些操作/检查。我喜欢这样一个事实：它全部就地布局，而不是作为另一个代码文件，不是某种配置文件，并且这一次，没有向类/方法添加另一个装饰。

我并不是说这是真正的 AOP - 我当然认为在某些解决方案和情况下它确实不是实现目标的最佳方式，但考虑到它只是几 K 的源文件，这使得轻量级实施。

AspectF 基本上是一种将委托链接在一起的非常聪明的方法。
我不认为每个开发人员都会查看代码并说它看起来多么美妙，事实上，在我们的办公室，它让我们中的一些人感到困惑！但是，一旦您了解了发生的情况，就会发现这是一种廉价的方法，可以实现其他方法也可以完成的大部分工作。