В чем преимущества и недостатки использования Service Locator в сравнении с одноточечным? Я читал, что синглтоны плохие, но мне интересно, будет ли Service Locator лучшим способом делать что-то.Singleton Vs ServiceLocator
Оба подхода плохи в том, что от договора класса не очевидно, каковы его «зависимости». То есть,
private void foo()
{
var x = SomeSingleton.Instance.GetX();
var y = ServiceLocator.GetService<IProvider>().GetY();
}
имеет ссылки на SomeSingleton и IProvider похоронены глубоко где-то внутри.
Однако, по сравнению с чистым одноэлементным подходом, локаторы обслуживания обычно намного лучше, поскольку они обеспечивают более простую централизованную конфигурацию, управление жизненным циклом и т. Д. Они также позволяют лучше тестировать (вы всегда можете макетировать вызовы на GetService<T>), нижняя муфта , разделение проблем и т. д.
Если тестируемость является проблемой, использование сервисного локатора намного лучше, чем чистые одноточие.
Я бы зашел так далеко, чтобы рассмотреть оба шаблона, но я согласен с тем, что Service Locator немного предпочтительнее. Лучшим решением было бы внедрение надлежащей инъекции зависимостей. –
из того, что я понимаю из DI, не потребуются ли все объекты, которые использовали для доступа к синглтону напрямую, чтобы иметь ссылку на ex-singleton-объект? – djcouchycouch
Да, вам нужно указать их в качестве параметров для конструктора (если вы используете инъекцию конструктора, это обычно называется «Объявлять ваши зависимости»). Чтобы немного облегчить это, вы можете использовать контейнеры Inversion of Control. Посмотрите на Google Guice. –