AOP and Why It is Important to Understand
What are Cross Cutting Concerns?
In life, business and software development there are “Vertical” and “Horizontal” activities.
Vertical activities are specific actions taken for a specific outcome.
You drive to work
You play a round of golf
You develop a database access layer for your application
These are Vertical Activities
In order to be successful with any of the above Vertical activities there were required Horizontal activities that were common to all of the Vertical activities.
Here are some of the Horizontal “Cross Cutting Activities” that you had to successfully accomplish for those Vertical life activities:
You had to get dressed
You had to consume food and water
Your vehicle required fuel
You required the tools of golf
These are Horizontal Activities
Your development deliveries require Cross Cutting Activities as well.
These activities are called Aspect Oriented Programming or AOP.
What is AOP?
There are common application required functionality that spans across multiple assemblies within a Business Technology solution.
Here is a list of the most common “Cross Cutting Concerns” that any well architected solution requires:
File and Database Logging
A Common Error and Exception Handling Process
A Database-centric Error and User Interface Messaging System
A Cryptology Schema
Services and Application Caching
Solutions are organized into projects that are create assemblies.
These assemblies represent the “Vertical” structures of your Business Architecture.
There have a single responsibility to the Domain.
They carry out the designed functions as requires by the Business Cases that warrant their existence within the Domain.
AOP and the Modern Developer
Good Object Oriented Programming requires compliance with Design Principles.
The Modern Developers Design Principles are categorized into “Core” and “Code” principles.
AOP helps us comply with the following Modern Developer’s Core Principles:
Single Responsibility Principle – Allows our code to concentrate on its Vertical responsibility and not the required Horizontal “Aspects” of the Cross Cutting Concerns such as Logging and Error and Exception Handling
Open Closed Principle – As Aspects are moved out of the code base into their Horizontal concerns we can manage the results of Logging and Messaging Cross Cutting Concerns without having to modify the consuming code base
The Dry Principle – When Aspects of our Cross Cutting Concerns are implemented as Vertical solutions the code base is required to duplicate the same functionality in every code block that requires the aspect such as Logging and Error and Exception Handling.
This duplication is very difficult to manage over time and violates the Don’t Repeat Yourself principle (DRY)
Inversion of Control Principle – When using the AOP technique of “Interception”, Inversion of Control (IOC) containers are used as the interception point for attaching our aspects
Dependency Inversion Principle – This principle creates the environment for AOP Interception using IOC containers by bubbling of the lower level dependencies for use for the IOC container objects available for AOP Interception
The AOP Architecture
In an AOP architecture each Vertical Assembly references these Horizontal Assemblies as Cross Cutting Concerns.
AOP concerns creates “Aspects” that the consuming assemble “Hook” for the required functionality such as Logging, Messaging, Error and Exception Handling and Security.
Aspect hooks are implemented with Attribute Aspect Declarations. The hooks can be placed at the Assembly, the Class, The Property, the Method and even the Field level.
The primary Event entry points for Aspects are:
OnEntry – Before the first line of code of the declared Aspect is run
OnExit – After the last line of code of the declared Aspect is run
OnSuccess– After the last line of successful code of the declared Aspect is run
OnError– Code that processes an Exception in a Try/Catch block and before the OnExit code is run.
The concept is to create common code that supports the code base.
This pattern abstracts away from the Developer the Horizontal concerns.
The AOP pattern also creates a uniform delivery
of functionality that costs the Client less
to support as changes are required
The Two Methods of Implementing Aspects
Aspects can be “Hooked” using one of the two primary mechanization:
Interception – Using IOC containers as the tool for “Intercepting” run-time requests for object usage that is being managed within the Lifetime Manage of an IOC container framework
IL Rewriting – Using an AOP solution that does “Post-Compilation Processing” to modify the code that gets sent as Intermediate Language (IL) code in the .NET platform
Interception extends IOC container frameworks with extensions that can intercept, at run-time, calls to objects being managed within their containers.
The interception can then run the registered and defined actions for the Aspect being called using the “Hook Points” defined in the Interception configurations.
IL Rewriting adds Post-Compilation functionality to our Code Compilation builds.
The framework adds our Aspects to the code after the normal compilation process is completed.
This delivers Intermediate Language, IL code, to the Just-In-Time compiler that has been rewritten for the Common Language Run-time (CLR) after the build process.
The AOP Frameworks
Unity, Spring IOC, StructureMap and NinJect are IOC containers that can intercept at run-time and implement Aspects.
We will be exploring the
Unity IOC Interception Extension
IL Rewriting Framework in .NET
PostSharp is the industry standard for IL Rewriting in .NET
We will be exploring
PostSharp IL Rewriting
The Next Step
Look for future Modern Developer Deep Dive posts for AOP.
There will be a Deep Dive into Unity for the Interception methodology and PostSharp for our AOP IL Rewriting methodology.
These two processes will be using
the TMD Portal
as out Showcase Solution
Wisdom Pearl # 137 – The Technical Imperative
The Primary Technical Imperative in Software Development
… Is to Manage Software Complexity
…… Always be able to Justify Your Designs Complexity
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services