Нужна помощь с реализацией шаблона Service Locator

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

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

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

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

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

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

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

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

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

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

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

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

Благодарность


java design-patterns service-locator
person Chris Knight    schedule 09.06.2011    source источник
comment
вы рассматривали внедрение зависимостей?   -  person akappa    schedule 09.06.2011
comment
@akappa да, я думал об этом. Я использовал Guice в прошлом, и он мне нравится (и, возможно, воспользуюсь им снова здесь). Тем не менее, мне нужно ввести всего несколько классов, и я решил узнать немного больше о шаблоне локатора сервисов.   -  person Chris Knight    schedule 09.06.2011
comment
Каким было ваше окончательное решение по вопросу 2, пожалуйста? Ресурсы будут оценены.   -  person ET13    schedule 11.02.2012
comment
@ ET13, в конце концов я понял, что Google Guice действительно имеет больше смысла, чем мой код локатора сервисов, поэтому я остановился на Guice. Прост в реализации и удовлетворил все мои потребности. Перечитывая вопрос выше, я думаю, что, вероятно, я бы пошел на загрузку конструктора реализаций по умолчанию, но, вероятно, зависит от ситуации.   -  person Chris Knight    schedule 12.02.2012

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Внедрение зависимостей и локатор службы не обязательно являются взаимоисключающими понятиями. Хорошим примером использования обоих вместе является фреймворк Avalon. Avalon использует локатор службы, но использует внедрение, чтобы сообщить компонентам, где найти локатор.

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

person Daff    schedule 09.06.2011