Шаблон локатора службы и DDD

У меня есть структура с уровнем данных DDD, который использует шаблон локатора службы. Однако в настоящее время я использую глобальный статический класс ServiceLocator, который хранит все ссылки. Я хотел бы реорганизовать это в правильную реализацию, где классы реализуют интерфейс IServiceProvider и где я удаляю глобальный статический класс ServiceLocator.Шаблон локатора службы и DDD

Теперь почти везде не требуется распространять существующие классы с интерфейсом IServiceProvider, за исключением классов сущностей. Проблема в том, что мне было бы очень странно, если бы классы объектов должны были реализовать IServiceProvider, но мне нужен способ получить доступ к поставщику услуг, чтобы иметь возможность разрешать репозитории через мой контейнер IoC.

Что было бы лучшим способом реализовать шаблон локатора сервисов без необходимости реализовать IServiceProvider на моих объектах?

источник

2012-02-20 Pieter van Ginkel

Можете ли вы разместить ссылку на шаблон, на который вы ссылаетесь? – jgauffin

Google имеет множество хороших результатов: http://www.google.com/search?q=service%20locator%20design%20pattern. Серия в http://stefanoricciardi.com/2009/09/25/service-locator-pattern-in-csharpa-simple-example/ идет немного подробнее. То, что я конкретно пытаюсь избавиться, - это шаблон singleton. –

Да, но это имеет нулевой смысл. Ничто в этих шаблонах не приводит к тому, что каждый объект подвергает IServiceProvider. – TomTom

Почему черт возьми объект (бизнес-объект) выставляет IServiceProvider? Это бизнес-объект, а не сервис. И IServiceProvider даже не для сервисов, это механизм МОК для выявления поставщиков услуг.

В любом случае структура ORM/бизнес-объекта/среда выполнения является поставщиком услуг, но не отдельными объектами.

позвольте мне вернуть вопрос: я не вижу разумной концепции программирования, где сущности подвергают IServiceProvider для начала.

--- обновить

Services только должны обеспечить локатор сервиса - и вы должны иметь один. Вы можете использовать потоковые статические переменные для тех случаев, когда определенные элементы доступа к потокам (например, пользовательский интерфейс - к элементам пользовательского интерфейса должен быть доступ по спецификации по потоку пользовательского интерфейса), который разбивает глобальный синглтон.

источник

2012-02-20 12:41:22 TomTom

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

Да, но это не сущности, это услуги. Также tehy не будет реализовывать IServiceLocator, но будет открыт через ServiceLocator. Вы можете уйти от использования зависимого объекта или другого центрального контейнера контейнера/сервиса (например, для каждого окна), но нет шаблона, в котором каждый объект превращается в один. – TomTom

Но мне они нужны в моей бизнес-логике. Проблема в том, что мне нужно иметь хороший способ получить доступ к этим сервисам из бизнес-логики. –

Локатор сервисов лучше всего использовать в сочетании с контейнером «Инверсия управления», таким как Unity, Castle Windsor или NInject. См. http://commonservicelocator.codeplex.com/wikipage?title=Unity%20Adapter&referringTitle=Home&ProjectName=commonservicelocator для примера локатора служб, который работает с Unity.

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

источник

2012-02-20 12:47:26

Я использую замок Виндзор. Однако я не считаю возможным, чтобы все зависимости проходили через, например, конструкторы все время. Я использую шаблон локатора службы специально для ряда глобальных служб, например. авторизации. –

Вы когда-нибудь приходили к идее использовать статический аксессор потока? Или используйте композицию post, чтобы иметь это свойство - я делаю это все время (позже). – TomTom

@TomTom: Я чувствую, что пост-композиция будет означать, что я все равно буду загрязнять объекты материалом, который не принадлежит ему. Я думаю, что статическим аксессуаром для потоков был бы путь. Если вы обновите свой ответ, я приму его. –

Вы имеете в виду шаблон Service Locator в ваших комментариях. Измените свой вопрос соответствующим образом.

Большинство приложений сегодня использует принцип внедрения зависимостей (D в принципах SOLID) вместо шаблона Service Locator. Самый простой способ начать работу с DIP - использовать инверсию управляющего контейнера типа Autofac.

Идея с Service Locator заключается в том, что у вас есть класс, который используется для поиска услуг. Для этого вам нужно иметь какой-то механизм регистрации для регистрации всех сервисов.

Типичный запуск:

serviceLocator.Add(new MyService());

А позже использование

serviceLocator.Get<MyService>();

Я рекомендую использовать DIP вместо поскольку она делает его намного понятнее, который зависимости класса имеет.

источник

2012-02-20 13:25:11 jgauffin

Обновлен вопрос. –

Шаблон локатора службы и DDD

ответ

Смежные вопросы