CODEWITHSUNDEEP
c#aopaspects
9b5b
9b5b

Reputation: 1528

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

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:

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:

Upvotes: 9

Views: 1585

Answers (2)

Simon Miller
Simon Miller

Reputation: 11

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.

Upvotes: 3

Mauricio Scheffer
Mauricio Scheffer

Reputation: 99750

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.

Upvotes: 5

Related Questions