introduction to aop. programming paradigm which aims to increase modularity by allowing the...
TRANSCRIPT
Introductionto AOP
Programming paradigm which aims to increase
modularity by allowing the separation of
cross-cutting concernsen.wikipedia.org/wiki/aspect-oriented-programming
Programming paradigm which aims to increase
modularity by allowing the separation of
cross-cutting concernsen.wikipedia.org/wiki/aspect-oriented-programming
Programming Paradigm
It is *NOT*- a programming language- solution to all your
problems- a first class citizen in Java
or .NET- a replacement for OOP
It is- a programming pattern
- a tool in your toolbox
- an easily added language feature
- complimentary to OOP
Modularity
Aspects can…• Exist in isolated and encapsulated constructs• Be attached to almost any standard code construct• Be transported between projects
Cross-Cutting Concerns
…aspects of a program that affect other concerns. These concerns often cannot be cleanly
decomposed from the rest of the system in both the design and implementation,
and can result in either scattering (code duplication),
tangling (significant dependencies between systems), or both.
http://en.wikipedia.org/wiki/Cross-cutting_concern
…more simply
Any code functionality that repeats itself in a regular pattern across many unrelated tiers/layers
within a codebase.
Cross-Cutting Concerns
Services
Domain Model
Repositories
Model
ViewModel
View
Logg
ing Se
curit
y
Audi
ting
Valid
ation
Undo/Redo
Thread Management
INotifyPropertyChanged
Unit of Work Management
Circuit Breaker
AOP Styles
1. InterceptionInterjecting the execution of cross-cutting concerns at run time.Non-invasive approach to modifying the code execution path.
2. IL WeavingInterjecting the planned execution of cross-cutting concerns during the compilation process.Invasive approach to modifying the code execution path.
Interception
• Existing in IoC container implementations• Follows a very strict decorator pattern• Likely implemented using weak typing• Run-time operation• Can be applied en-masse• Easy to implement if you’re already using IoC
Decorator Pattern
//new functionality before//the code that already exists//new functionality after
//exception handling
Weak Typing
En-masse Attachment
IL Weaving
• Post compilation process• Alters the assembly/executable at an IL level• Scary to people• Can be attached to almost every code construct• Very rare that it required changes to existing code• Run and compile time operations• Can be much easier to add to legacy code
The Process
Write CodeCompile
Application exe/dll
AOP post compiler/weav
er
Throw compile-time
error
exe/dllDeploy
Constructs
• Methods (private/public/internal/etc)• Properties• Field level variables• Events• Event registration/de-registration• Code generation
Run Time vs Compile Time
Run Time• All aspect code executes in application context
Compile Time• Code can be designated to run during post-compilation• Compilation can fail for correct syntaxes but incorrect
business logic
Tooling
• Interception• Castle Winsdor• StructureMap• Ninject (with Ninject.Extensions)• AutoFac (with Autofac.Extras)
• IL Weaving• PostSharp (current)• LinFu
The Traditional Arguments Against AOP
• It is “magic”• We won’t be able to debug properly• How do we know where aspects will be executed?• It’s another thing we have to learn• Changing the aspect will break the entire application
“Its magic!” & “We can’t debug it!”
• Both interception and IL weaving provide full line-by-line debugging• Attachment of aspects is explicit as you want it to be
“But which aspect(s) will run?”
• This is a tooling/discoverability problem, not a problem with AOP itself• PostSharp has very good VS integration showing what
aspects are attached to a piece of code• Interceptor discoverability is a bigger problem
“Its another thing we have to learn”
Is it worse if we train them and they leave or if we don’t
train them and they stay?
“Changing the aspect can break the entire application!”
• You can probably do that in an number of different ways with any codebase that doesn’t use AOP• This is a problem caused by tight coupling and poor
separation of concerns
Your Project is Already Established…
You use IoC• For logging, caching and possibly transaction
management use interception• If the cross cutting concerns are more complex
(Undo/Redo, thread management) use IL Weaving
You don’t use IoC• The only real option is to use IL Weaving
You’re Starting a New Project…
You have AOP buy-in from senior developers• Start with IL Weaving, but start with simple, pre-built
aspects• Write custom aspects as experience and need grows
AOP is still unknown to the senior people on the team• Start with IL Weaving, but start in a very isolated
manner• Use this as a proof of concept until you have senior
level buy-in
