По мотивам прочтения вот этого поста http://sgdev-blog.blogspot.sg/2014/07/spring-mvc-common-mistakes.html
В web приложениях со springframework, я чётко разделяю srping-овыйе контексты -
- mvc.xml: настройки, относящиеся к view, а точнее к "внешнему" web-взаимодействию (сюда входят намапленные web-контроллеры, ресурсы и т.п.)
- services.xml: настройки, которые содержат непосредственно компоненты логики, в том числе, связки с БД, репозитории, и т.п.
Собственно, сделано это, чтобы не грузились компоненты по два раза, в двух контекстах. А в статье указанной выше описано почему это происходит и разумные рекомендации. Которым я оказывается уже следую.
Чего я не знал, и что иногда имеет важное значение - это последовательность загрузки контекстов.
1. Сначала грузится тот контекст, что описан в ContextLoadListener(в моём случае services.xml)
2. Потом, при инициализации сервлета, грузится контекст, описанный в DispatcherServlet (mvc.xml в параметре contextConfigLocation или, по умолчанию, ${servlet.name}-context.xml)
В web приложениях со springframework, я чётко разделяю srping-овыйе контексты -
- mvc.xml: настройки, относящиеся к view, а точнее к "внешнему" web-взаимодействию (сюда входят намапленные web-контроллеры, ресурсы и т.п.)
- services.xml: настройки, которые содержат непосредственно компоненты логики, в том числе, связки с БД, репозитории, и т.п.
Собственно, сделано это, чтобы не грузились компоненты по два раза, в двух контекстах. А в статье указанной выше описано почему это происходит и разумные рекомендации. Которым я оказывается уже следую.
Чего я не знал, и что иногда имеет важное значение - это последовательность загрузки контекстов.
1. Сначала грузится тот контекст, что описан в ContextLoadListener(в моём случае services.xml)
2. Потом, при инициализации сервлета, грузится контекст, описанный в DispatcherServlet (mvc.xml в параметре contextConfigLocation или, по умолчанию, ${servlet.name}-context.xml)
Комментариев нет:
Отправить комментарий