ShakyJake
<Donor>
- 7,963
- 20,076
Yes, although it's really not that complicated. Basically the concept is that you are not tying your objects to a concrete implementation of any of their dependencies.
A simple example:
In this example we are tying our AccountsController to a concrete version of the AccountsRepository (which are instantiating it in the Controller's constructor). The repository class may be tied directly to database access. Situations like this makes testing difficult because, in order to test, we have to have a functional database with data, etc. Additionally, in the future, if we decide to change the AccountsRepository to a new implemention - like AccountsRepostioryII or something, we would need to go back and change our Controller class to use this new version.
However, with DI we do this:
Here, we areinjectingthe repository object into the controller's constructor. The class now has no knowledge of what the instantiation details of the IRepository interface. In this instance, testing is easy because the IRepository object can be a mock object that has whatever data we may need for testing. And we can easily change the concrete implementation of IRepository without having any need to change the controller class.
Make sense?
