…no lo es. Veo en smart421 lo que el autor considera un uso apropiado del patrón ServiceLocator:

public class Controller : IController
{
    private readonly IServiceLocator _serviceLocator;
    public Controller(IServiceLocator serviceLocator)
    {
        _serviceLocator = serviceLocator;
    }

    public void Execute<TContext>(TContext context)
    {
        var command = _serviceLocator.GetInstance<ICommand<TContext>>();

        if (!command.IsNull())
        {
            command.Execute(context);
        }

        var disposable = command as IDisposable;

        if (disposable != null)
            disposable.Dispose();
    }
}

En mi opinión, esa clase debería ser así:

public class Controller : IController
{
    private readonly ICommandFactory _factory;
    public Controller(ICommandFactory factory)
    {
        _factory = factory;
    }

    public void Execute<TContext>(TContext context)
    {
        var command = _factory.Create<TContext>();

        // La comprobación de IsNull sobra. Si alguien intenta ejecutar
        // un ICommand para un Context que no existe, es que hay un bug.
        command.Execute(context);

        factory.Destroy(command);
    }
}

Aparentemente, lo único que hemos hecho ha sido cambiar una dependencia sobre un IServiceLocator, por una dependencia sobre un ICommandFactory, que además es más limitada y permite hacer menos cosas.

Pues bien, esa es la diferencia, que ICommandFactory permite hacer menos cosas, es decir, tiene una resposabilidad mucho más definida que IServiceLocator. Esto hace que quede mucho más claras cuales son las necesidades de IController, y además evita que podamos «hacer locuras» dentro de él.