Some people say that it is better to use dependency injection. Why is that?
I think it is better to have few global, easy accessible classes, rather than huge constructors.
Does it influence application speed in any way?
Mix of these two would be probably the best.
The main advantage will be decoupling, which will help with unit testing. This sort of depends entirely on how you code these "easily accessible classes".
The idea is this. A class decouples from implementation (class) dependencies by only having a dependency on the contract (interface). In your live environment you may never provide a new implementing class, but in your test environment you very likely will (be it a handmade stub, or a mocked class from a mocking framework).
Application speed would need profiling, but the use of a framework for DI would likely incur some overhead instead of you talking directly to a singleton that you know about. The important question: is this overhead a problem? Only performance expectations and profiling can tell you that. In my experience, the benefits far outweigh the negligible performance detriment.
You will probably be using static classes and methods as your Globals. They do not have any performance implication. However, static classes do not lend themselves to testability.
What are the downsides to static methods?
Moreover, once your code becomes tightly coupled to static classes (Globals) you will not be able to replace them with alternate implementations in the future. So Globals may not be good design unless used in very simplistic situations.
Note that static classes and methods are compile time binding where as DI is run time binding. Helps you keep your classes loosely coupled.
There is an huge difference between using "globals" and DI. First the path is usually not direced because you probably steps through singleton and service locator. Both are considered somehow an anti-pattern today. The reason is that we are supposed to design code testable, that give us great advantages when we need to change the code base for maintainance or for satisfying new requirements. Testability is easy to achieve if code is decoupled. As you guess global behaviors does not help in decoupling, so for example if you have code acceding a static singleton, to test such a code you need the singleton itself, you can't mock it, and this is bad since you can't stress your system as you please. Service locator seems at a first glance better: you could mock the service locator evantually if you need to test, but you have to:
DI on the constructor is a good way in code decoupling because you state very clearly what the object needs to run, and you can decide in a glance what to mock, stub and so on. Pay attention that DI will works and helps you just if you ensure not having the DI kernel walking as a dependency across your code: this would transorm the DI in an antipattern ( you decouple the code, but you bind it to a container ), so remember to study and really implement the composition root pattern, this will really hlep you to write better and testable code.
I think the top post on this topic has a very good summary of DI and how to use it in the right way: Dependency Inject (DI) "friendly" library
If you want to dive deeper into the topic, i can recommend the book "Dependency Injection in .NET" by Mark Seeman.
