Небольшой совет. Я нашел полезным модульное и четкое обозначение контекстных файлов Spring xml на основе требований приложения. Вот пример для веб-приложение, которое я работал на:
MyProject/src/main/resources/spring /
- datasource.xml - Мой единственный источник данных боб.
- persistence.xml - My DAOs/Repositories. Зависит от
datasource.xml
бобы.
- services.xml - Реализации уровня обслуживания. Обычно это бобы, к которым я применяю транзакцию с использованием АОП. Зависит от
persistence.xml
бобы.
- controllers.xml - Контроллеры My Spring MVC. Зависит от
services.xml
бобы.
- views.xml - Мое представление реализаций.
Этот список не является ни совершенным, ни исчерпывающим, но я надеюсь, что это иллюстрирует точку. Выбирайте любую стратегию именования, и гранулярность лучше всего подходит для вас.
В моем (ограниченном) опыте, я видел этот подход следующее получал метод преимущества:
Clearer архитектура
Очевидно именованные файлов контекст дает тех, кто незнаком с вашей структурой проекта разумного места для начните искать определения бобов. Может упростить обнаружение круговых/нежелательных зависимостей.
Помогает дизайну Доменные
Если вы хотите добавить определение бина, но это не вписывается ни в одном из ваших контекстных файлов, возможно, есть новая концепция или озабоченность развивающихся? Примеры:
- Предположим, вы хотите сделать свой сервисный уровень транзакцией с АОП. Вы добавляете эти определения бобов в
services.xml
или помещаете их в свои transactionPolicy.xml
? Расскажите об этом своей команде. Если ваша политика транзакций должна быть подключаемой?
- Добавить Acegi/Spring Security beans в ваш файл
controllers.xml
или создать контекстный файл security.xml
? У вас разные требования к безопасности для разных развертываний/сред?
Интеграционное тестирование
Вы можете телеграфировать подмножество приложения для тестирования интеграции (например: учитывая вышеуказанные файлы, чтобы проверить базу данных, необходимо создать только datasource.xml
и persistence.xml
бобы).
В частности, вы можете аннотировать в тестовый класс интеграции как таковой:
@ContextConfiguration(locations = { "/spring/datasource.xml" , "/spring/persistence.xml" })
хорошо работает с Бобы Spring IDE ГРАФ
Имея много сфокусированных и хорошо именованных контекстных файлов позволяет легко создайте пользовательские BeansConfigSets, чтобы визуализировать слои вашего приложения с помощью Spring IDE Beans Graph. Я использовал это раньше, чтобы дать новым членам команды обзор на высоком уровне организации нашего приложения.
Должно ли это быть одновременно? Решение по одному будет проще, если вы новичок в обоих (неясно, является ли Java EE для вас новым). – SteveD 2009-08-24 20:57:52