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?

Husky

This is highly subjective, I'd make this CW – Durkheim

I don't want to be mean or rough, but the author of AspectF kind of missed the point of AOP. It's not AOP not because of technical choices, it's not AOP because the cross cutting concern is still entangled with business logic. Which is the precise issue AOP tries to solve. – Cloaca

Perhaps I've unfairly presented the famework. He indicates that one of the main goals of AspectF is "separation of concerns". You may want to check out the posts I've now included in the question to clarify the author's intent of what AspectF is actually trying to do... – Kweilin

@Jon: I've read the posts and the codeproject article and I agree with Jb, this misses the point of AOP. – Durkheim

Anyway, AOP appart, I like the idea behind AspectF and I am using it to achieve good code factorization. I have add additionnal "AspecFlets" (calling it so...) in my apps to perform enclosing tasks as connections .Open() and .Close(), or Controls handling as .Beginupdate() .Endupdate(), or to handle exception a common way... – Mellisamellisent

Because of intensive lambda expression use, this project is an "Edit And Continue" killer. – Mellisamellisent

I can see how that would be a pain point. Though I feel in a way the lambda expresssion cat is out of the bag and so they are found everywhere now. – Kweilin

I like it, but it ruins my edit and continue experience. Lambdas cannot be edited during execution. – Mellisamellisent

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.

Durkheim

Answer 2

On a recent project, it was recommended to me that I give AspectF a try. I took to heart the idea of laying all the concerns up front, and having the code that does the real work blissfully unaware of all the checks and balances that happened outside of it.

I actually took it a little further, and added a security "concern" that required credentials that were being received as part of a WCF request. It went off to the database and did what it had to. I did obvious validations, and the security check before running the actual code that would return the required data.

I found this approach quite a refreshing change, and I certainly liked that I had the source of AspectF to walk through as I was debugging and testing the service calls.

In the office, some argued that these concerns should be implemented as a decoration on a class / method. But it doesn't really matter where you decorate it, at some point somewhere, you need to say you wish to perform certain actions / checks. I like the fact that it's all laid out in-place, not as another code file, not as some kind of configuration file, and for once, not adding yet another decoration to a class / method.

I'm not saying it's true AOP - and I certainly think there are solutions and situations where it really isn't the best way of implementing your objectives, but given that it's just a couple of K of source files, that makes for a very light-weight implementation.

AspectF is basically a very clever way of chaining delegates together. I don't think every developer is going to look at the code and say how wonderful it is to look at, indeed in our office it confused some of us! But once you understand what's going on, it's an inexpensive way of achieving much of what can be done by other approaches too.

Paulitapaulk