Здравствуйте, Sinix, Вы писали:

S>По-моему, эта проблема общая для любой _динамической_ системы разруливания зависимостей и нюансы конкретной реализации тут мало что решают. Особенно с типовым для биз-логики требованием "настраиваемый объект может _динамически_ создавать другие настраиваемые через DI объекты".

Лично для меня разница всё-таки есть. Вот два примера:

//1
public A(ServiceLocator locator) {
  var repository = locator.GetService<IRepository>();
}

//2
public B(IRepository repository) {
}

Казалось бы действие одно и то же. Но тестировать второй вариант значительно проще, чем первый, так как у нас есть контракт которому нужно соответствовать.
Если же у нас по коду класса раскаданы вызовы GetService, то это неизменно приводит к тому что тесты сыпятся в рантайме, что не есть хорошо.

Для себя обозначил такое правило: "ServiceLocator не должен встречаться в тестируемом коде".

Здравствуйте, Sinix, Вы писали:

S>По-моему, эта проблема общая для любой _динамической_ системы разруливания зависимостей и нюансы конкретной реализации тут мало что решают. Особенно с типовым для биз-логики требованием "настраиваемый объект может _динамически_ создавать другие настраиваемые через DI объекты".

Лично для меня разница, всё-таки, есть. Вот два примера:

//1
public A(ServiceLocator locator) {
  var repository = locator.GetService<IRepository>();
}

//2
public B(IRepository repository) {
}

Казалось бы, действие одно и то же. Но тестировать второй вариант значительно проще, так как у нас есть контракт которому нужно соответствовать.
Если же у нас по коду класса раскаданы вызовы GetService, то это неизменно приводит к тому что тесты сыпятся в рантайме, а это не есть хорошо.

Для себя обозначил такое правило: "ServiceLocator не должен встречаться в тестируемом коде".