-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove dependency resolver dependency from the Bus #85
Comments
The issue is related to #86 |
Why such dependency is violation of dependency inversion? Contour is a kind of the IoC container by itself. If you look to another IoC container: Web API, NServiceBus, MassTransit, you will see the same approach with the dependency resolver. |
All dependencies should be unaware of the host which binds them together. In this case the dependencies, or parts, are really separable from each other and do not interfere with the way the whole system is composed. This promotes testability and removes the need for weird types like AppConfigConfigurator. |
Could you describe how to implement last two requirements briefly:
|
I suggest that the configuration should be passive and should be only evaluated on bus configuration. As such the host should instantiate a bus and resolve the bus dependency on configuration provider registered in the host's DI-container. Later on when the bus has acquired a configuration provider it should validate it and evaluate the result of a "factory"-type which holds a list of consumer types, registered by the business service. When this happens the bus should juxtapose the configuration with the list of the provided consumer types. Thus only the consumers which have configuration provided will be used. At this point the bus has all the data needed to be started by the host. |
Feature specification:
The text was updated successfully, but these errors were encountered: