Spring -MVC: что такое "контекст" и "пространство имен"?

Из XmlWebApplicationContext javadoc:

По умолчанию конфигурация будет взята из "/WEB-INF/applicationContext.xml" для корневого контекста и "/WEB-INF/test-servlet.xml" для контекста с пространством имен "test-servlet" "(например, для экземпляра DispatcherServlet с именем сервлета" test ").

Что означает контекст Spring?

Каков корневой контекст? Какие еще виды контекста Spring существуют?

Что такое пространство имен?

UPDATE:

Некоторые последующие вопросы:

  • Что такое Spring ApplicationContext - это какая-то "вещь", которая содержит beans, которые определены в файле конфигурации конфигурации?

  • Рассматривая код ContextLoaderListener, он выглядит так, как будто он загружает данные, определенные в файле конфигурации XML. Но мое веб-приложение Spring работает без определения этого слушателя или любого другого слушателя. Как это могло быть?

  • В каких сценариях имеет смысл иметь более одного экземпляра Spring DispatcherServlet?

  • Является ли корневой контекст (data из applicationContext.xml) применимым к каждому экземпляру DispatcherServlet, тогда как другие контексты (например, данные из test-servlet.xml) применимы только к соответствующему DispatcherServlet (т.е. test)?

Ответы

Ответ 1

"Spring context" = a Spring ApplicationContext.

"корневой контекст", с точки зрения веб-приложения, означает основной контекст, который загружается и используется webapp. Как правило, вы начинаете корневой контекст с ContextLoaderListener.

Корневой контекст на самом деле не является "добрым" контекстом. Это просто роль, которую играет контекст. У вас есть один корневой контекст в webapp. Другие контексты не являются корневым контекстом. Обычно это дети корневого контекста.

Здесь пространство имен относится к области экземпляра Spring DispatcherServlet. Все это говорит о том, что если вы назовете свой "тест" сервлета в своем web.xml, то по соглашению Spring будет искать файл с именем "test-servlet.xml" для использования в качестве этого контекста диспетчера. Кстати, каждый такой контекст, который создается для диспетчера, становится потомком корневого контекста.

Изменить: Чтобы ответить на ваши новые вопросы:

  • Следуйте ссылке в первой строке моего ответа, чтобы узнать о ApplicationContext. Если у вас есть вопросы, на которые вы не ответили, я бы предложил опубликовать новый вопрос SO.
  • Корневой контекст не является обязательным. Если у вас нет определенного ContextLoaderListener, тогда у вас просто нет корневого контекста. Когда вы используете DispatcherServlet, он запускает собственный ApplicationContext, и он получит от него beans.
  • Я не знаю одного из моих ног. Я полагаю, что если в некоторых приложениях URL-адреса вашего приложения возникла необходимость в совершенно разных конфигурациях, это может заставить вас сделать это.
  • Да. Чтобы правильно указать его, корневой контекст является родительским контекстом любого контекста, запущенного для DispatcherServlet. beans в родительском контексте доступны через дочерний контекст, но обратное неверно.

Ответ 2

В веб-приложении архитектура обычно делится на слои, такие как популярная структура MVC. Таким образом, веб-приложение содержит в основном слой, который обрабатывает клиентские запросы, т.е. HTTPRequests и слой, который обслуживает эти запросы.

Подводя итог: классы, предназначенные для обработки запросов Http, т.е. контроллеры, которые сопоставлены с URL-адресами, попадают под test-servlet.xml. Это называется WebapplicationContext, содержащим только beans, которые требуются главным образом для обработки клиентских запросов.

Теперь следующая часть - это уровень Service/Dao, который состоит из вашей бизнес-логики. beans, которые выполняют такую ​​логику, загружаются в объект ApplicationContext.

Теперь вы можете спросить, почему они разделили эти вещи на файлы или два разных объекта.

Это потому, что приложение имеет ту же бизнес-логику, которую могут использовать несколько клиентов, работающих на разных протоколах. Вы можете использовать одни и те же уровни обслуживания для обработки RMI, а также для HTTP-вызовов. Таким образом, Spring создал родительский контекст, который запускается нами как ApplicationContext. И затем, если ваше приложение обрабатывает веб-запросы, вы можете создать сервлет диспетчера, который имеет свой собственный Webapplicationcontext и инициализируется как дочерний элемент родительского контекста. Таким образом, все родительские beans могут ссылаться на дочерние элементы и могут быть переопределены, но не наоборот