UnityContainer.Resolve или ServiceLocator.GetInstance?

Это может показаться глупым вопросом, потому что в моем коде все работает, но я зарегистрировал синглтон таким образом с контейнером Unity _ambientContainer:

 _ambientContainer.RegisterType<Application.StateContext>(new ContainerControlledLifetimeManager());

Чтобы избежать использования моего локального поля, я использую:

get {
    return ServiceLocator.Current.GetInstance<Application.StateContext>();
}

внутри моего свойства get, чтобы получить экземпляр моего объекта. Таким образом, я получаю всегда один и тот же экземпляр (Application.StateContext все еще одноэлементный) или GetInstance создает новый?

Лучше ли использовать локальное поле _ambientContainer?

get {
    return _ambientContainer.Resolve<Application.StateContext>();
}

Спасибо.

Ответ 1

Я предполагаю, что тип ServiceLocator находится из проекта CommonServiceLocator и что вы используете адаптер Unity, и в этом случае GetInstance вызывает container.Resolve, поэтому обе строки эквивалентны.

Здесь вы можете посмотреть источник - http://commonservicelocator.codeplex.com/wikipage?title=Unity%20Adapter&referringTitle=Home

Ответ 2

Прохождение экземпляров контейнера в потребительские классы обычно не является хорошей идеей, поскольку вам больше не гарантировано иметь место в вашем приложении, где регистрируются компоненты и службы (известный как Корень композиции).

Классы должны указывать свои зависимости в своем общедоступном API, в идеале указывая их как аргументы конструктора, которые контейнер будет автоматически предоставлять экземпляр для всякий раз, когда его просят разрешить определенный тип (процесс, известный как Autowiring).

Инъекция зависимостей обычно предпочтительный вариант но это не всегда применимо. В тех случаях, когда "Locator" , как вы делаете в своем примере, является следующим лучшим решением для отделить класс от его зависимостей.

В заключение, если Injection Dependency не является вариантом, я бы не хотел, чтобы мои классы напрямую ссылались на контейнер и вместо этого они могли получить доступ к нему через локатор сервисов.

Ответ 3

Предпочтительно вам следует избегать обоих способов (ab) с помощью вашего контейнера.

ServiceLocator считается анти-шаблоном в современной архитектуре приложений.