Поскольку вопрос спорный, я не собираюсь говорить "используйте то или другое"
Похоже, что использование Service Locator не является плохой вещью, если вы можете положиться на него (и мы обычно так или иначе делаем на некоторой платформе DI). С помощью DI мы можем легко изменить структуру, а с помощью Service Locator мы создаем связь с частью SL платформы.
Что касается ответа Брайана Уоттса, когда вы будете читать дальше в
Сервисный локатор против внедрения зависимостей
... При внедрении [constructor] явный запрос отсутствует, служба появляется в классе приложения - отсюда инверсия управления .
Инверсия управления - это общая черта фреймворков, но это то, что имеет свою цену. Как правило, это трудно понять и приводит к проблемам при попытке отладки. Так что в целом я предпочитаю избегать этого, если мне это не нужно. Это не значит, что это плохо, просто я думаю, что нужно оправдываться над более простой альтернативой.
И затем, если вы прочтете позже, это еще одно оправдание для фактического использования инжектора конструктора (инверсия управления).
Мое мнение таково, что в небольших проектах нормально использовать SL, так как главное - не создавать связь между нашими специально разработанными классами.
При использовании структуры StructureMap это должно быть приемлемо:
public class Demo
{
private ISomething something = ObjectFactory.GetInstance<ISomething>();
private IFoo foo = ObjectFactory.GetInstance<IFoo>();
}
Да, код зависит от SM Frx, но как часто вы меняете DI Frx?
А для юнит-тестирования можно настроить макет
public class SomeTestClass
{
public SomeTest()
{
ObjectFactory.Inject<ISomething>(SomeMockGoesHere);
ObjectFactory.Inject<IFoo>(SomeMockGoesHere);
Demo demo = new Demo() //will use mocks now
}
}
Преимущества использования Resolve вместо Constructor Injection в том, что вам не нужно создавать классы с 5 параметрами в конструкторе
, но вы можете сделать больше «сантехники» для модульного тестирования.