Remove dependency on StructureMap #335
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Could you please take a look at this when you have a chance, @BiggerNoise? |
|
The codacy hint it bullsh*t, btw, this is an implementation of an interface. I can't make it static... |
|
Also agree that the service locator approach should be replaced, but this is an excellent step forward |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current DI pattern in RoundhousE is somewhat Service Locator based, so coding away the concept of a global, static
Containterclass is a bit more of a job. IMHO, dependencies should be set up and injected into the consuming classes/components from one "starting point" in the program (typicallyMain()in a console app), and not registered in a single, static container. But this is probably a discussing point.Without changing the overall architecture, since we don't use any of the more advanced feature of a DI container (pooling, disposing instances, etc), I have replaced StructureMap with a single hard-coded "Container" that serves the purpose of a backend to how we use the static
Container.Resolvein RoundhousE.It's no rocket science, but since we had problems with StructureMap, and StructureMap is abandoned, we might as well get rid of the dependency. The fewer dependencies, the better, as long as we don't have to invent very advanced wheels ourselves, IMHO.
This solves #327 (hopefully).