Enterprise Dependency Injection for Future Proofing Apps

A introduction level talk about how BlueBolt uses dependency injection to make application components and dependencies easy to implement and replace, while making code more maintainable.

Transcript

1. Enterprise Dependency Injection for Future Proofing Apps
2. Disclaimer • This talk represents my own options and views not the opinions of my employer or their employees. • Dave is Cool • He didn’t ask me to do this.
3. Who Am I? • I have been working as a .NET developer since 2005 • Throughout that time I have been focused on developer practices. • I have worked for 8 fortune 500 companies and 3 nationally recognized non-profits in a consulting role. • My current role at BlueBolt Solutions is Security Engineer / Enterprise Architect / Solutions Developer • I am around the internet under the handle @punkcoder
4. What is Dependency Injection (DI)? • Dependency injection is a way of decoupling classes • It’s a form of Interface Based Programming • It includes a “container” • This comes in two forms: • Injecting major dependencies • Inject all the things…
5. Why it’s Important • Dependency Injection forces you into separating your applications into small replaceable pieces. • Dependency Injection allows for quick mocking and unit testing. • Dependency Injection makes code more flexible.
6. Dependency Injection Patterns
7. Dependency Injection vs. Inversion of Control • DI is a form of Interface Based Programming • IoC is a pattern of controlling the instantiation though dependency injection.
8. Common Issues with DI • DI is Slow • DI is difficult to follow • DI introduces needless complexity • DI can mess up unit testing and make it more complicated
9. DI Frameworks • Castle Windsor (https://github.com/castleproject/Windsor) • Structure Map (https://github.com/structuremap/structuremap) • Spring.Net (https://github.com/spring-projects/spring-net) • Autofac (https://github.com/autofac/Autofac) • Unity – Dead / Complete • Nfactory – Dead / Complete • Ninject – (https://github.com/ninject/Ninject) • Puzzle.NET – Dead / Complete • S2Container (http://s2container.seasar.org/2.4/en/index.html) • PicoContainer.Net – Super Dead / Complete • LinFu (https://github.com/philiplaureano/LinFu) - Complete / Dead????
10. DI Frameworks Continued • TinyIoC (https://github.com/grumpydev/TinyIoC) • Caliburn.Micro • Catel • DryIoc • Dynamo • fFastInjector • Funq • Grace • Griffin • HaveBox • IfInjector • LightCore • LightInject • Maestro • MEF • Microsilver • Microsoft.Framework.DependencyInjecti on • Mugen • Munq • Petite • SimpleInjector • Stashbox
11. What we use… • We use ninject… • Lessons Learned: • Know the package • Control the Life Cycle • Is this the BEST solution… No, But… • It achieves what we want… • We were able to completely change our DAL layer in 3 hours. • It is easy to read and understand • It is fast, for our solution it is ~550ms on startup.
12. Static Kernel
13. Yes, but not that simple.
14. Simple Get
15. Secondary Get ( withSelector )
16. Get All Instances
17. … this one needs a little explanation • To enable the processing of plugins from other libraries. • We dynamically load interfaces from the application specifically looking for instances where we want to load all.
19. Here’s where the magic happens…
20. Demo : Application Magic
21. Demo: New DAL
22. Demo: Plugin
23. Our Kernel - Gist
24. Summary
25. Evals – No Seriously… • Feed back is the only way I can improve and the only way that amegala can help to get only the best speakers. • http://prairiecode.amegala.com/evals • http://prairiecode.amegala.com/evals