Is it possible to do DI without any third party tools? I've read about people doing it with an abstract class and interface before they discovered some DI framework. How is ID done in that very basic form?
相关问题
- Generic Generics in Managed C++
- How to Debug/Register a Permanent WMI Event Which
- 'System.Threading.ThreadAbortException' in
- Bulk update SQL Server C#
- Should I use static function in c# where many call
Of course it's possible without third-party tools. Simple sample:
SomeClass
takes anILogger
as input in the constructor. It uses it for logging some output. Let's say we want it in the console:In some code:
..but then we want the log in a file instead:
So, we inject the file logger instead:
SomeClass
is happily unaware of theILogger
implementation in use, and just uses whichever implementation that is injected. It's usually a good idea to have a factory creating the instances of the interface implementations instead of having the objects constructed all over the code, in order to make it simpler to change the implementation in use.There is a nice description in this tutorial.
Basically what you do is that you let the
DependingClass
only know about anInterface
, and then you implement that interface with yourIndependentClass
. With constructor overloads, you let for example a unit testing framework send in a mock object.Some code might make it easier to understand what I'm getting at:
Now, as you see, we have provided a default class type that will be instantiated if no argument is provided to the constructor. But we have also allowed for injection of a different class that implements the same interface, or a mock object of the same.
EDIT: As pointed out in a comment, it is probably better in a larger app to have a factory that instantiates the
DependingClass
, and remove the "default" constructor. That way you only have to change in one place if you decide to change the implementation.You can create your components communicating with each other through interfaces and have your hosting program that instantiates the components and link them together.
This would be your solution structure:
An dll assembly that defines the contract between components (interfaces + data objects that are part of the interface methods signatures).
One ore more dll assemblies that defines your components (that implement interfaces). Any communication between components is done through interfaces.
An exe assembly that starts up the hosting process, instantiates the components and link them setting some properties. Whenever you need to substitute one component you only need to change this project.
You can create unit tests for any of your components mocking up the components that are used by the component you are testing.
Also you can get fancy reading the property bindings from the app.confing file in the hosting project.
There are three ways you can do it...
Pass the reference to the dependant instance (which is an instance of a class that implements the interface of course) in the constructor.
Create the new object and then pass the reference to the dependant object via a property setter
Use a function within the object that accepts the reference and assigns it to the internal provbate variable you have created for this
Just pass the dependencies to the constructor of the class when you instantiate it. No DI frameworks are needed when the project is small (below a couple of thousand lines of code) - you can write a factory and wire up all the dependencies manually.