Нужна помощь в реализации шаблона Service Locator - PullRequest
1 голос
/ 09 июня 2011

У меня есть небольшое веб-приложение, которое я создаю.Прежде всего, чтобы улучшить мои возможности модульного тестирования (а также развязать код), я реализую шаблон локатора службы для поиска конкретных реализаций некоторых зависимостей.Я в основном доволен самим одноэлементным классом Service Locator, но мне любопытно, куда его поместить и как его загрузить.Синглтон по существу управляет хэш-картой интерфейса -> конкретные реализации.

У меня есть несколько проектов в моей рабочей области:

1) Проект уровня представления, который содержит код сервлета и обработку уровня представления.(использует 2 и 3 ниже)

2) Проект уровня доступа к данным, который содержит код для доступа к базам данных и т. д. (использует 3 ниже)

3) Общий проект, содержащий различные данныеМодели используются обоими слоями.(нет других ссылок на проекты)

Поскольку локатор служб предназначен для обслуживания реализаций классов в обоих проектах 1 и 2 выше, мне интересно, где его лучше всего поставить?

Еще один вопрос, который я задаюЯ застрял на том, как лучше загрузить его с реализациями по умолчанию.Один из вариантов - поместить все реализации по умолчанию в конструктор класса локатора службы singleton.Например:

private ServiceLocator() {
   services.put(ISomeClass.class, new SomeClass());
   ....
}

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

Итак, я предполагаю, что у меня два вопроса:

1) В каком проекте работает ServiceLocatorлучше всего подходит?

2) Какие решения вы рекомендуете для загрузки класса с реализациями по умолчанию?

спасибо

1 Ответ

1 голос
/ 09 июня 2011

Я думаю, что статья Мартина Фаулера о Внедрение зависимостей отвечает на некоторые ваши вопросы. Лично я не самый большой поклонник шаблона поиска сервисов, особенно в Java, где есть много высококачественных DI-фреймворков (хотя, по общему признанию, это может быть излишним, но так как вы должны подумать об этих архитектурных решениях по реализации Сервисный локатор уже может понадобиться в любом случае в любом случае). На ваши вопросы:

1) Я бы сказал, в отдельном проекте, который зависит от 1) и 2) 2) Из упомянутой статьи:

Инъекция зависимости и сервис локатор не обязательно взаимно эксклюзивные концепции. Хороший пример используя оба вместе это Авалон фреймворк. Авалон использует сервис локатор, но использует инъекцию, чтобы сказать компоненты, где найти локатор.

Таким образом, вы также можете использовать внедрение зависимостей, чтобы заполнить локатор реализациями по умолчанию.

...