Sadek Drobi’s Blog

As Aspect Oriented Programming is getting more and more known, a lot of wrong usages appear. Surprisingly, I’ve seen common agreement among J2ee/.net architects for applying it in their application architectures.

First of all, Aspects are not only about the Spring’s  code injection by interception. Even if it looks like interesting, this style of AOP use can be misapplied. One of these misapplications is in transactions. I ve heard it a lot, “All my services are transactions” or “All methods that end with service are transactions” and worse “all of this package (assembly) is transactional!”

Transactions are a part of business logic, they should be explicit in the code, and they should belong to whatever layer they need to belong to. Transactions are not automatic, and cant be applied as an aspect of a whole layer or as an architecture decision.

Yet applying them as Aspects (Aspect) Attributes or Tags is explicit, but they should not be exclusive to somewhere in the architecture, THEY ARE NOT A PART OF THE ARCHITECTURE!

I like the .Net’s implementation of TransactionScope in System.Transactions. It fits rather good to the functional meaning of transactions. I still prefer to have a more explicit code that expresses and treats them. After all, EBay is Transactionless (talking about database technical transactions) and Amazon doesn’t do any Distributed Transactions! That confirms that transactions should be treated as business  notions rather than technical.

I guess it wont be very intresting for readers if I introduce an aspect for loggin all my events and ideas to this weblog! Even if it would be much eaiser for me Beleive me, that would be floody!