В примерах spring4d, ServiceLocator.GetService<MyType>('Name') используется для разрешения типов. Но почему бы не использовать GlobalContainer.Resolve<MyType>('Name')? Я не вижу каких-либо преимуществ в этом подходе ...Лучшая практика для решения в Spring4D?
Существует один случай использования, где я использую: поиска сервиса при кодировании сделать унаследованного кода проектов юнит-проверяемым ...
Существует старая project, где в многолистных местах есть вызовы конструктора объекта, в который я пишу тесты (новые и измененные методы только в классах, где инъекция невозможна, например, когда форма создается и уничтожается в событии кнопки).
В юнит-тестов, spring4d полезно создать экземпляр класса испытуемый:
я могу использовать GlobalContainer в ДПР для проекта производства и специальный (тест только) TContainer-объект, который построенный в Testfixture.Setup и уничтожен в Testfixture.TearDown ... Я также повторно инициализирую глобальный Service-Locator для использования моего тестового контейнера (Причина: у меня плохой опыт использования GlobalContainer в тесте, вы не можете отменить регистрацию типа от GlobalContainer в Testfixture.TearDown).
Итак, теперь у меня есть большой метод в dpr, где я регистрирую все типы в GlobalContainer в проекте производственного кода. В методе установки моего класса test-fixture я регистрирую все типы, необходимые для теста, в моем тестовом контейнере. И в методах, которые я изменил, чтобы сделать их модульными, я строю классы-под-тестом с ServiceLocator, где ранее использовались конструктор-вызовы.
Для меня это единственный способ сделать такой блок проекта с устаревшим кодом, который можно тестировать ... Но моя стратегическая цель - заменить большую часть этого кода (частично по части, включая повторно инициализированные ServiceLocators) один день. Сейчас его невозможно заменить (слишком много затрат, слишком много риска ...).
oh ok, поэтому в основном ваша единственная причина использовать сервисный локатор - это возможность изменить подкладочный контейнер - звучит разумно –
Не единственная причина ... Атрибут [Inject] просто невозможно ... жизненный цикл некоторых объектов просто внутри метода ... как это сделать с помощью [Inject]? – Markus
невозможно Я бы сказал –
[Некоторые] (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) считают [сервисный локатор] (http://stackoverflow.com/questions/22795459/is-servicelocator- анти-шаблон) анти-шаблон. Я бы рассмотрел альтернативы для обоих. –
Поскольку оба используют глобальные переменные, они не круты, да. Но есть ли у вас предложение альтернативы? –
Я думаю, вы можете просто убедиться, что вы используете контейнер только в [CompositionRoot] (http://stackoverflow.com/questions/6277771/what-is-a-composition-root-in-the-context-of- зависимостей) приложения, а затем либо будет таким же, как и до тех пор, пока граф объекта будет полностью сконструирован в корне композиции (а на контейнере не указано вне этого местоположения), то локатор службы функционально одинаков как инъекция зависимости. –