Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

container.Register<IFoo, Foo>();//я очень надеюсь, что интерфейс IFoo необязателен и регистрировать можно просто Foo.
container.Register<IFoo, AnotherFoo>("AnotherFoo"); // В самом деле? магические строки?!
var instance = container.GetInstance<Bar>();// Service Locator?!! фтопку.

container.RegisterInstance<string>("SomeValue");
var value = container.GetInstance<string>();// в контекст суём тип string?!!

var someValue = "SomeValue";
var anotherFoo = new AnotherFoo();
var instance = new Bar(anotherFoo, someValue);

S>А иногда получается, что проще оставить DI как хелпер для автоматического заполнения статически известных зависимостей, а сами зависимости протаскивать через контекст, который по факту тот же самый service locator, вид сбоку. В общем, не всё так однозначно

class A
{
   B b;
   void methodA()
   {
     P prm = calculateParam();
     b.methodB(prm);
   }
}
class B
{
   C c;
   void methodB(P prm)
   {// мы тут prm не используем, но его приходится протаскивать в зависимость C
     c.methodC(prm);
   }
}
class C
{
  void methodC(P prm)
  {
    use(prm);
  }
}

class A
{
    B b;
    ParamContext paramContext;
    void methodA()
    {
        P prm = calculateParam();
        paramContext.set(prm);
        b.methodB();
        paramContext.clear();// using/try-finally по вкусу
    }
}
class B
{
// теперь тут вообще тип Param не упоминается.
    C c;
    void methodB()
    {
        c.methodC();
    }
}
class C
{
    ParamContext paramContext;
    void methodC()
    {
        P prm = paramContext.get();
        use(prm);
    }
}

class A
{
    B b;
    C c;
    void methodA()
    {
        P prm = calculateParam();
        c.prm = prm;
        b.methodB();
        c.prm = null;// using/try-finally по вкусу
    }
}
class B
{
// теперь тут вообще тип Param не упоминается.
    C c;
    void methodB()
    {
        c.methodC();
    }
}
class C
{
    Param prm;
    void methodC()
    {
        use(prm);
    }
}

S>Ага. Ну эт вопрос вкуса фломастеров уже

S>var someService = GetConfirmationService(someParams.Consumer);
S>someService.PostConfirmation(....)
S>

confirmationService.postConfirmation(someParams.Consumer, ...);

final class SmartConfirmationService implements IConfirmationService {
  final IConfirmationService poorManNotifications;
  final IConfirmationService premiumNotifications;

  public SmartConfirmationService(
      IConfirmationService poorManNotifications, 
      IConfirmationService premiumNotifications) {
    this.poorManNotifications = poorManNotifications;
    this.premiumNotifications = premiumNotifications;
  }

  @Override
  void postConfirmation(Consumer consumer, ...) {
    if (consumer.hasPremiumSubscription)
      premiumNotifications.postConfirmation(consumer,...);
    else
      poorManNotifications.postConfirmation(consumer, ...);
  }
}

// Somewhere in init:
final IConfirmationService smsConfirmationService = new SMSConfirmationService(gateway, ...);
final IConfirmationService mailConfirmationService = new MainConfirmationService(...);
final IConfirmationService confirmationService = new SmartConfirmationService(smsConfirmationService, mailConfirmationSerivce);

final class SomethingDoer {
  final IConfirmationService confirmationService;
  void doSomething(...) {
    ...
    confirmationService.postConfirmation(...);
  }
}

void methodA(Entity someEntity) {
  final Params params = getParams(someEntity);
  methodB(params.a, params.c, params.d, someEntity.piece);
}

methodB(int a, int b, int c, EntityPiece d) {
  methodC(a, b, c, d)
}

void methodA(long entityId) {
  methodB(entityId);
}

void methodB(long entityId) {
  methodC(entityId);
}

void methodC(long entityId) {
  UsedParams status = doSomeSqlQuery(entityId);
  if (status > 3)
    doSomethingWithAnotherCoolQuery(enitityId, status);
}

S>[Import]
S>internal IClassificationTypeRegistryService ClassificationRegistry;

S>[Import]
S>ITextBufferFactoryService textBufferService;
S>

internal var ClassificationRegistry = Locator.get(IClassificationTypeRegistryService.class);
var textBufferService = Locator.get(ITextBufferFactoryService.class);

IQ> Для обоснования своей позиции я написал целый пост. Для обоснования своей вы не написали и одной полной строки. Несимметрично.

IQ>В последнее время, мне как раз попадались реализации big ball of mud исключительно с DI

IQ>global variable и service locator и что в них плохого на ранних этапах развития проекта?

Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры".

Модули верхних уровней не должны зависеть от модулей нижних уровней

IQ>>>и приложенными enterprise проектами

IQ>Ну вы то пока даже с "лажей" поста не запилили, одно нытье и литании.

public class HomeController : Controller

    public HomeController(
        BoringItemDataReader,
        BoringItemDataWriter,
        BoringItemChildDataReader,
        BoringItemChildDataWriter,
        AppDataJsonConverter,
    ...
)

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая...

SomeSerivce someService = someSerivceFactory.getByConsumer(consumer);
someService.doA(boo);
somethingElse(someService.doB(baa));
someService.doC(mee);
andSoOn(someService, foo);

M>void methodA(Entity someEntity) {
M>void methodA(long entityId) {

1. SL. В подавляющем числе случаев он не нужен. Проблема — он делает зависимости неявными.
   
2. методы-инициализаторы и property injection. Проблема — добавляет в объект опасное состояние "создан, но не очень-то ещё создан".
   
3. Магические строки. Ничем не лучше магических чисел.
   
4. Сканирование сборок. В подавляющем числе случаев он не нужен. Доставляет столько удовольствия исследовать что куда залетело и почему. Притом это можно исследовать только на запущенной системе в данном (часто prod) окружении.
   
5. Циклические зависимости. С DI+CI сделать цикл невозможно. Заставляет аккуратнее подходить к архитектуре приложения, а не всякие lazy/PI, которые тебе циклы создадут на ура.

var foo = fooProvider.giveMeFoo();
doSomethingWith(foo);

public void businessLogicMethod()
{
    using(var foo = fooProvider.giveMeFoo())
    {
        doSomethingWith(foo);
    }
}

if(useDatabase)
{
    using(var foo = new DatabaseFoo(connectionString))
    {
        doBusinessLogicWith(foo);
    }
}
else
{
    var foo = new InMemoryFoo();
    doBusinessLogicWith(foo);
}

Tom>Так не надо его использовать. Контейнер то тут причём

container.Register<IFoo, Foo>();
var instance = container.GetInstance<IFoo>();

public static void main(args)
{
  var app = new AppModule();
  app.run(args);
}

Tom>·>Я знаю. Сам таким был.

Dependency injection separates the creation of a client's dependencies from the client's behavior, which allows program designs to be loosely coupled[7] and to follow the dependency inversion and single responsibility principles.[4][8] It directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies.

The different injector implementations (factories, service locators, and dependency injection containers) are not that different as far as dependency injection is concerned.

var kernel = KernelFactory.Build();
kernel.Rebind<IConfigProvider>().To<Mock1>().InSingletonScope();//ребиндим от чего у нас компонент зависит.
kernel.Rebind<IService>().To<Mock2>().InSingletonScope();
var c = kernel.Get<IComponent>();

static class LoggingFactoryProvider { ILogFactory get; }
static class WebServiceProvider { IWebService get; }

IQ>Вооот! Вот с этого и надо было начинать! А то объясни, докажи, покажи код А все это бессмысленно, если оппонент — религиозный фанатик упорствующий в ереси.

1. big ball of mud
   
2. global variable
   
3. service locator

IQ>и приложенными enterprise проектами