author:czy
DI pattern (Dependency Injection) frees us from the sophisticated construction of the depended objects.
In the business view, it helps the developers concentrate on the the business domain without any worries on the initialization of the depended objects.
In the architecture view, it facilitates the reuse of the component as the depended objects are resolved in the DI.
Let’s take the design of TeamView as an example.
There is a JIRAImportControl to import the JIRA system output xml to the TeamView. The uml diagram goes as following.
From the diagram, we can see the dependency between CreateDbForm and JIRAImportControl is quite neat.
We can easily move JIRAImportControl to another container without much more coding than let the DI construct JIRAImportControl in that container.
However, if we give up DI, let’s see what hell would be.
Without the DI’s help, the additional dependencies come up to us. I admit that the some additional dependencies in the diagram would be a little overstated. However, if we want to resue the JIRAImportControl in another container, we have to take DBConnection construction and ItemImporterImpl construction (God bless that ItemImporterImpl would have no dependencies) into consideration. If the other container can’t supply the necessary parameters to the constructions, the design of container itself must be changed. So, the hell appears that changes happen over the system just to satisfy a little change in a little corner.
There are many perfect DI framework, we use autofac as the DI.
Additionally, please go to our website novasoftware for more information about the team.