1 / 26

Introduction to AOP

Introduction to AOP. Programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns en.wikipedia.org/wiki/aspect-oriented-programming. Programming paradigm which aims to increase modularity by allowing the separation of

talulah-taylor
Download Presentation

Introduction to AOP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introductionto AOP

  2. Programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns en.wikipedia.org/wiki/aspect-oriented-programming Programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns en.wikipedia.org/wiki/aspect-oriented-programming

  3. 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

  4. Modularity Aspects can… • Exist in isolated and encapsulated constructs • Be attached to almost any standard code construct • Be transported between projects

  5. 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

  6. …more simply Any code functionality that repeats itself in a regular pattern across many unrelated tiers/layers within a codebase.

  7. Cross-Cutting Concerns View INotifyPropertyChanged ViewModel Logging Security Validation Undo/Redo Model Thread Management Services Auditing Domain Model Unit of Work Management Repositories Circuit Breaker

  8. AOP Styles • Interception Interjecting the execution of cross-cutting concerns at run time. Non-invasive approach to modifying the code execution path. • IL Weaving Interjecting the planned execution of cross-cutting concerns during the compilation process. Invasive approach to modifying the code execution path.

  9. 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

  10. Decorator Pattern //new functionality before //the code that already exists //new functionality after //exception handling

  11. Weak Typing

  12. En-masse Attachment

  13. 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

  14. The Process Write Code Compile Application exe/dll Throw compile-time error AOP post compiler/weaver Deploy exe/dll

  15. Constructs • Methods (private/public/internal/etc) • Properties • Field level variables • Events • Event registration/de-registration • Code generation

  16. 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

  17. Tooling • Interception • Castle Winsdor • StructureMap • Ninject (with Ninject.Extensions) • AutoFac (with Autofac.Extras) • IL Weaving • PostSharp (current) • LinFu

  18. 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

  19. “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

  20. “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

  21. “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?

  22. “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

  23. 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

  24. 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

  25. graciasDonald Belcham @dbelcham donald.belcham@igloocoder.com

More Related