9

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

他创建了一个名为AspectF的框架，这是“一种将 Aspect 添加到代码中的流畅且简单的方法”。

这不是真正的 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 的设计与其说是 AOP 的替代品，不如说是一种实现“关注点分离并保持代码整洁”的方式。

一些想法/问题：

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

2 回答 2

5

我并不是要抨击这个项目，但恕我直言，这是在滥用 AOP。Aspects 并不适合所有东西，这样使用只会影响可读性。

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

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

性能方面没有损失（或者可以忽略不计），因为没有运行时 IL 操作，正如 codeproject 文章中所解释的那样。但是，我从来没有遇到过 Castle DynamicProxy 的任何性能问题。

于 2009-11-02T17:30:02.380 回答
3

在最近的一个项目中，有人建议我尝试 AspectF。我牢记将所有关注点放在首位的想法，并且让执行真正工作的代码幸福地不知道发生在它之外的所有制衡。

实际上，我更进一步，并添加了一个安全“关注点”，该“关注点”需要作为 WCF 请求的一部分接收的凭据。它去了数据库并做了它必须做的事情。在运行将返回所需数据的实际代码之前，我进行了明显的验证和安全检查。

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

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

我并不是说它是真正的 AOP——而且我当然认为在某些解决方案和情况下它确实不是实现目标的最佳方式，但鉴于它只是几个 K 源文件，这使得非常轻量级实现。

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

于 2011-09-09T13:32:58.550 回答