Skip to content
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

Open
semion-akimtsev opened this issue May 15, 2017 · 5 comments
Open

Remove dependency resolver dependency from the Bus #85

semion-akimtsev opened this issue May 15, 2017 · 5 comments

Comments

@semion-akimtsev
Copy link
Contributor

semion-akimtsev commented May 15, 2017

Feature specification:

  • the bus should not depend on the dependency resolver of any kind (soliD violation);
  • the bus configuration should be done with at least two types of providers: code and file;
  • the file configuration provider should not depend on dependency resolver (service locator etc.); external dependency resolver should build a configuration provider, a bus and pass the provider to the bus for it to configure itself;
  • all consumers discovered by the service locator should be passed to the bus by the "host" (HostBox etc.);
@semion-akimtsev
Copy link
Contributor Author

The issue is related to #86

@mzabolotko
Copy link
Contributor

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.

@semion-akimtsev
Copy link
Contributor Author

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.

@mzabolotko
Copy link
Contributor

Could you describe how to implement last two requirements briefly:

external dependency resolver should build a configuration provider, a bus and pass the provider to the bus for it to configure itself;
all consumers discovered by the service locator should be passed to the bus by the "host" (HostBox etc.);

@semion-akimtsev
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants