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

В моем проекте мы начали использовать фреймворк Spring. Познакомившись с основными функциями (IoC), мы начали использовать защиту Spring aop и Spring.

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

Вопрос:

Существует ли наилучшая практика организации Spring файлов?

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

Ответ 1

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

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

Ответ 2

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

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

applicationContext.xml
securityContext.xml
schedulingContext.xml
dataSourcecontext.xml
spring -ws-servlet.xml(Spring связанные с веб-службами beans)

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

sharedMainApplicationContext.xml
sharedGuiContext.xml
sharedSecurityContext.xml

Файлы, специфичные для приложения:

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

Я бы выполнил рекомендации 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 vs аннотации

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

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

Ответ 7

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