Since this never got answered, I'll give it a go here. And hopefully my understanding is correct.
A Service Locater is a class that knows where to find a class and return it when requested. It doesn't know how that is to be instantiated, so it's not Factory.
The DI Container (or IoC Container, if you will) also knows where to locate classes, and can determine the class to be inserted into a class' constructor at the time of instantiation. That's a mouthful and vague, I know. And I might be fuzzy on the differences. Here's an example of my understanding of a "true DI container".
You have a class that you want to instantiate. It requires an instance of another class to be passed into it's constructor.
Code:
class User {
public function __construct( App\UserModelInterface User_model )
{
....
}
}
The User_model is passed in and saved as a property of the class. Since it's an interface, you can easily swap out different versions to get passed to the class. This is helpful for testing, as mentioned, because you can pass in a mock class. However, it's also extremely handy when working on a v2 of an app. You can create a new User_model that is specific to v2 of the app, but still implements the same methods (and adheres to the interface requirements), but does things differently. Alternatively, you could have different User_models that have different storage services. Maybe one stores the data in a local database that you want to use in development, but you have another for production that uses two different databases for read and write queries, and caches to a Redis setup.
The DI Container allows you to simply configure it to know WHAT classes should be passed into the User class, and it will automatically pass in an instance of the Dependency. It will do the same thing for any dependencies the User_model might have, also.
Hopefully that makes sense, though I'm not sure I did a great job explaining it.
From a framework viewpoint, it could be used the same way, but allows you to very easily change the way the framework works by simply telling the DI Container to use a different class when it's creating dependencies. At that point, there is no need for MY_Router files (or whatever). If you want to modify the way the router works, you simply create a new class that adheres to the Router Interface, and let the DI Container know to use your class. Now, any place the Router class is needed, your new class is automatically used.
That's the true beauty of a DI Container.
