LightInject for ASP.Net Core
- 1. LightInject for Asp.Net Core Shawn Vause Senior Web Applications Engineer @ ZOLL LifeVest January 10, 2017
- 2. Overview Inversion of Control Out of the Box Replacements for Asp.Net Core LightInject Questions
- 3. Inversion of Control Mechanism/Technique Dependency instances bound at runtime Instances/implementations of abstractions not known at compilation time Loose coupling of dependencies Maintenance/Modification Testability S – Single Responsibility O – Open/Closed L – Liskov Substitution I – Interface Segregation D – Dependency Injection SOLID Principles
- 4. Out of the Box Feature IServiceProvider Constructor Injection + Framework Provided Services (MVC, Entity Framework, Identity, etc.) + Transient Lifetimes + Singleton Lifetimes + Scoped Lifetimes + Named Type Injections - Explicit use of resolved constructor parameters - Registration Fallbacks - Custom Lifetimes - Property Injection - More… -
- 5. Replacements for Asp.Net Core AutoFac Simple Injector StructureMap LightInject
- 6. LightInject Feature IServiceProvider LightInject Constructor Injection + + Framework Provided Services (MVC, Entity Framework, Identity, etc.) + - Transient Lifetimes + + Singleton Lifetimes + + Scoped Lifetimes + + Named Type Injections - + Explicit use of resolved constructor parameters - + Registration Fallbacks - + Custom Lifetimes - + Property Injection - + More… - +
- 7. LightInject Step 1 – project.json
- 8. LightInject Step 2 – Startup.cs
- 10. LightInject Recommendations Strongly consider a project specific to dependency injection activities Build extension method classes for registrations Out of box strengths in conjunction with full-fledged IOC library (best of both worlds) Ex: All the framework registration activities
- 11. LightInject
- 12. References Sample Project https://github.com/napalm684/ReciPiBookCore LightInject https://github.com/seesharper/LightInject.Microsoft.DependencyInjection
Editor's Notes
- #4: Mechanism/Technique Helps us accomplish SOLID principle of dependency injection
- #7: We get all the robustness we are used to in an IOC library It is a lot like Unity which per Jeff Fritz that project/team has disbanded at MS Work on-going in open source to try and port but seems to have stalled
- #11: Recommendations Strongly consider a project specific to dependency injection activities Build extension method classes for registrations **BOTH KEEPS STARTUP.CS SIZE DOWN** Out of box strengths in conjunction with full-fledged IOC library (best of both worlds) Ex: All the framework registration activities **EXAMPLES TYPICALLY WORK WITH OUT OF BOX IOC, LEVERAGE THAT REMEMBERING LightInject etc BOLT ON TO OUT OF BOX**
- #12: We have all seen the above registration which would give us the ability to inject a dbcontext to a consumer DbContext is inherently difficult to test or mock out Repositories introduced to get around this/make life easier Generic Repositories reduce duplication of “standard” database code What if my application uses multiple database I don’t want to couple the repository just to RecipesDb in this case. I can use named registrations to have multiple registrations for a single type and tell the repository for a given registration what database to use that is registered in the container.