Dependency Injection Support?
See original GitHub issueHas any thought been given to DI support in Obvs?
It tends to be very hard to go back and bake in support for DI into frameworks later. Is it worth introducing low level support for dependency resolution now while it’s early goings to avoid the pain later? You could either introduce a proprietary IDependencyResolver
interface as part of Obvs core or have Obvs take a dependency on the Microsoft.Framework.DependencyInjection
package which would come with the added benefit of everyone implementing direct support for that for all the popular containers (e.g. AutoFac, Ninject, Unity, etc.) since it’s a building block of all the new frameworks in .NET vNext. The downside of taking the dependency on that is that it’s still beta and that would mean the version of Obvs that takes that dependency would need to be a beta version itself until that dependency RTMd.
Issue Analytics
- State:
- Created 8 years ago
- Comments:8 (6 by maintainers)
Top GitHub Comments
I think @MovGP0’s final post sums up perfectly the accepted approach to Obvs + DI. Closing this.
it is actually quite easy. just create a factory method that sets up the service bus using the fluid interface. then you can inject the factory method. Create additional factory methods for alternative configurations and mocks as needed.
Dependency Injection
Factory Method:
using DryIoc:
Mocking
using Moq:
using DryIoc:
Usage
Injecting bus:
Creating bus when needed: