Is AspectF (a Fluent Aspect Framework) an AOP-like design that can be used without much concern?

Question

Omar Al Zabir is looking for "a simpler way to do AOP style coding".

He created a framework called AspectF, which is "a fluent and simple way to add Aspects to your code".

It is not true AOP, because it doesn't do any compile time or runtime weaving, but does it accomplish the same goals as AOP?

Here's an example of AspectF usage:

    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);
                });
    }

Here are some posts by the author that further clarify the aim of AspectF:

• AspectF fluent way to put Aspects into your code for separation of concern (Blog)
• AspectF (google code)
• AspectF Fluent Way to Add Aspects for Cleaner Maintainable Code (CodeProject)

According to the author, I gather that AspectF is not designed so much as an AOP replacement, but a way to achieve "separation of concern and keep code nice and clean".

Some thoughts/questions:

• Any thoughts on using this style of coding as project grows?
• Is it a scalable architecture?
• performance concerns?
• How does maintainability compare against a true AOP solution?

Answer 1

I don't mean to bash the project, but IMHO this is abusing AOP. Aspects are not suitable for everything, and used like this it only hampers readability.

Moreover, I think this misses one of the main points of AOP, which is being able to add/remove/redefine aspects without touching the underlying code.

Aspects should be defined outside of the affected code in order to make them truly cross-cutting concerns. In AspectF's case, the aspects are embedded in the affected code, which violates SoC/SRP.

Performance-wise there is no penalty (or it's negligible) because there is no runtime IL manipulation, just as explained in the codeproject article. However, I've never had any perf problems with Castle DynamicProxy.