Организация контекстных файлов Spring и лучшие практики

Question

Мы начали использовать Spring Framework в моем проекте. После ознакомления с основными функциями (IoC) мы начали использовать Spring AOP и Spring Security.

Проблема в том, что у нас теперь есть более 8 различных контекстных файлов, и я чувствую, что мы недостаточно продумали организацию этих файлов и их роли. Новые файлы были представлены по мере развития проекта. У нас есть разные контекстные файлы для: метаданных, aop, авторизации, сервисов, веб-ресурсов (это приложение RESTful). Поэтому, когда разработчик хочет добавить новый компонент, не всегда ясно, в какой файл он должен его добавить. Нам нужна методология.

Вопрос:

Есть ли лучший способ организации весенних файлов?

Должны ли контекстные файлы инкапсулировать слои (DAL, Business Logic, Web) или варианты использования? или течет?

Answer 1

Если вы все еще в начале проекта, я бы посоветовал вам обратить внимание на конфигурацию на основе аннотаций. После преобразования в аннотации у нас есть только 1 XML-файл с определениями, и он действительно довольно мал, и это большой проект. Конфигурация на основе аннотаций делает акцент на вашей реализации, а не на xml. Это также более или менее удаляет довольно избыточный уровень абстракции, который является пружинным «именем бина». Оказывается, что имя компонента существует в основном , потому что из xml (имя компонента все еще существует в конфигурации аннотаций, но в большинстве случаев не имеет значения). После этого включите большой проект, и все на 100% согласны с тем, что он лучше на лот , и у нас также есть достаточно приличные доказательства того, что это более продуктивная среда.

Я бы действительно рекомендовал любому , кто использует пружину для переключения на аннотации. Также возможно смешать их. Если вам нужен совет по переходному периоду, я думаю, что легко спросить об этом;)

Answer 2

Начните с applicationContext.xml и отделяйте, когда есть много bean-компонентов, которые имеют что-то общее.

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

• applicationContext.xml
• securityContext.xml
• schedulingContext.xml
• dataSourcecontext.xml
• spring-ws-servlet.xml (связанные компоненты Spring Web Services)

Для клиентов с графическим интерфейсом, поскольку в этом проекте их несколько, есть одна папка с общими контекстными файлами, и, кроме того, у каждого клиента есть собственная контекстная папка. Общие контекстные файлы:

• sharedMainApplicationContext.xml
• sharedGuiContext.xml
• sharedSecurityContext.xml

Файлы приложений:

• mainApplicationContext.xml и
• guiContext.xml и
• commandsContext.xml (структура меню)
• sharedBusinessLayerContext.xml (бины для подключения к серверу)

Answer 3

Файлы контекста Spring содержат определения bean-компонентов, поэтому я думаю, что лучше всего следовать принципу ОО и структурировать их так же, как вы строите свои классы в пакетах. Обычно мы создаем пакеты для инкапсуляции набора классов, которые работают вместе для решения конкретной проблемы. Пакет обычно инкапсулирует горизонтальный уровень (уровень базы данных, промежуточное программное обеспечение, бизнес-логика или их часть). Есть случаи, когда пакет содержит классы, которые соответствуют горизонтальному слою (вариант использования или поток, как вы упомянули). В общем, я бы рекомендовал создать один файл контекста для каждого пакета или набора пакетов. Когда вы добавляете новый компонент, добавьте его в файл контекста, соответствующий пакету класса.

Конечно, это не должно быть очень строгим правилом, поскольку могут быть случаи, когда было бы полезно следовать другой практике.

Answer 4

Я бы следовал рекомендациям Spring и поместил файлы контекста в META-INF/spring, как описано в документации Spring Roo . В общем, я бы рекомендовал попробовать roo и следовать их структуре и макету проекта.

Пример

src/
+-- main/
|   +-- java/
|   \-- resources/
|       +-- META-INF/
|       |   \-- spring/                    ‹ normal spring context files
|       |       +-- context.xml
|       |       \-- context-services.xml
|       \-- other files
|
+-- test/
|   +-- java/
|   \-- resources/
|       +-- META-INF/
|       |   \-- spring/                    ‹ context files for testing
|       |       +-- context-test.xml
|       |       \-- context-dao-test.xml   
|       \-- other files
|
\-- pom.xml

Spring XML против аннотаций

Есть много хороших статей по этой теме, но я хотел бы разбить распространенное заблуждение, потому что оба подхода имеют свои преимущества: если вы хотите отделить конфигурацию от фактической реализации, с XML это проще, но с аннотациями можно добиться того же, что и Крозенволд сказал . Однако при использовании файлов конфигурации XML имена бинов требуются только в том случае, если на бин нужно ссылаться напрямую. Вы всегда можете использовать автоподключение по имени или по типу.

Единственно важным является то, что вы должны оставаться последовательными на протяжении всего проекта или, по возможности, в рамках проектов вашей компании.

Answer 5

Да - разделить на похожие роли для бобов в нем. Что касается аннотаций, я полагаю, что они «могут» играть небольшую роль, возможно, с определениями транзакций, но в противном случае они просто навсегда связывают ваш код, и вы также можете добавлять ссылки (или любые другие сторонние) напрямую везде. Для меня аннотации = ярлык и технический долг. Они не конфигурируются извне, поэтому нет ничего сложного в том, чтобы переписать или связать ваш код и ограничить повторное использование. Данный бин навсегда застрял со своими аннотированными зависимостями и конфигурацией, поэтому он не может использоваться несколькими проектами / процессами одновременно с разным подключением и конфигурацией. только мои 2 цента.

Answer 6

Я обнаружил, что разбил их по слоям.

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

Answer 7

Разбиение конфига на отдельные файлы полезно для меня с точки зрения тестирования. В небольшом проекте я помещу конфигурацию Spring Security в «securityContext.xml», а остальные компоненты в «applicationContext.xml». Затем во время выполнения интеграционных тестов легко включить или отключить безопасность, просто решив, включать ли securityContext.xml. В некотором смысле это похоже на AOP, так как вы добавляете больше функций в приложение, выбирая, включать ли определенные файлы.