Eric on AOP, my answers

Eric asks here what scenarios would AOP encapsulate for us and would be useful for us. Here are a few I can think of:

·         Automatic Transaction, pooling declaration (see EntrepriseServices)

·         Automatic Object relocation (see remoting, but think message pipe)

·         Logging certainly

·         An alternative to code injection and hooks (that WILL be required at some point or another, windows have it, and there’s no other way to put a compatibility layer on compiled files)

·         Viewable: Let’s add behavior to a method when it can be called from WMI for example.

Are these doable without AOP support? Yes, by using two main patterns:

·         Context Bound Objects and sinks: Suffers from the loss of garbage collector in IPC and cross appdomains configuration (frankly, a domain where the Microsoft story is just plain bad)

·         Providing an architecture and using reflection: doable, but then you need to:

o       Standardize on a constructor pattern, such as abstract factories. Means changing an API, ok for new code like indigo, sucks for old code.

o       Rewrite code and recompile, which means AOP modules can’t be swapped at deployment time without recompilation.

The main tenant of AOP is to be able to NOT couple the aspect and the code. If you do couple, then CBO is ok (if someone can get cbrumme to launch a project for a faster tp creation, correct the distributed garbage collection across processes and appdomains on a single machine), and the custom construction patterns is fine. If not, then you can’t do much…