Spring-MVC: Co to jest "kontekst" i "przestrzeń nazw"?

Question

Od XmlWebApplicationContext javadoc:

Domyślnie konfiguracja zostanie wzięte z „/WEB-INF/applicationContext.xml” w kontekście głównego i „/WEB-INF/test-servlet.xml” dla kontekst z przestrzenią nazw "test-serwlet" (jak dla instancji DispatcherServlet z nazwą serwletu "test").

Co to jest kontekst wiosenny?

Co to jest kontekst główny? Jakie są inne konteksty wiosny?

Co to jest przestrzeń nazw?

UPDATE:

Niektóre follow-up pytania:

1. Co to Wiosna ApplicationContext - jest to jakiś "rzeczą", która posiada ziarna, które są zdefiniowane w pliku XML konfiguracji?

2. Patrząc na kod ContextLoaderListener, wygląda na to, że ładuje dane zdefiniowane w plikach konfiguracyjnych XML. Ale moja aplikacja internetowa Spring działa bez definiowania tego słuchacza lub jakiegokolwiek innego słuchacza. Jak to mogło się stać?

3. W jakich sytuacjach warto mieć więcej niż jedno wystąpienie Spring's DispatcherServlet?

4. Czy kontekst główny (dane z applicationContext.xml) ma zastosowanie do każdej instancji DispatcherServlet, podczas gdy inne konteksty (np. Dane z test-servlet.xml) mają zastosowanie tylko do odpowiedniego obiektu DispatcherServlet (tj. Testu)?

Answer 1

"Kontekst wiosny" = a Spring ApplicationContext.

"Kontekst główny", w znaczeniu aplikacji internetowej, oznacza główny kontekst załadowany i wykorzystywany przez aplikację webową. Zazwyczaj kontekst korzenia rozpoczyna się od ContextLoaderListener.

Kontekst główny nie jest tak naprawdę "rodzajem" kontekstu. To tylko rola, którą odgrywa kontekst. Masz jeden kontekst główny w aplikacji internetowej. Inne konteksty nie są kontekstem źródłowym. Zazwyczaj są dziećmi kontekstu głównego.

Przestrzeń nazw odnosi się tutaj do zakresu instancji Spring's DispatcherServlet. Wszystko wskazuje na to, że jeśli nazwiesz serwlet "test" w twoim web.xml, to zgodnie z konwencją, Spring będzie szukał pliku o nazwie "test-servlet.xml", który będzie użyty jako kontekst tego dispatchera. Nawiasem mówiąc, każdy kontekst taki jak ten, który jest tworzony dla dyspozytora, staje się dzieckiem kontekstu głównego.

Edit: Aby odpowiedzieć na nowe pytania:

1. Śledź link w pierwszym wierszu moją odpowiedź poznać ApplicationContext. Jeśli masz pytania, na które nie ma odpowiedzi, proponuję opublikowanie nowego pytania SO.
2. Kontekst główny jest opcjonalny. Jeśli nie zdefiniowano ContextLoaderListener, po prostu nie ma kontekstu głównego.Podczas korzystania z DispatcherServlet, uruchamia on własny ApplicationContext, i dostarczy potrzebne komponenty z tego miejsca.
3. Nie znam ani jednego z czubków głowy. Przypuszczam, że gdyby istniała potrzeba drastycznie odmiennych konfiguracji między niektórymi zasobami adresów URL w Twojej aplikacji, może to skłonić Cię do zrobienia tego.
4. Tak. Aby podać go we właściwym znaczeniu, kontekstem głównym jest kontekst nadrzędny dowolnego kontekstu uruchomionego dla DispatcherServlet. Fasola w kontekście nadrzędnym jest dostępna przez kontekst dziecka i odwrotnie, ale nie jest prawdą.

Answer 2

W aplikacji internetowej architektura jest zwykle podzielona na warstwy, takie jak popularna struktura MVC. Tak więc aplikacja internetowa składa się zasadniczo z warstwy, która obsługuje żądania klientów, tj. HTTPRequests oraz warstwa obsługująca te żądania.

Podsumowując: klasy, które mają obsłużyć żądania HTTP, tj. Kontrolery odwzorowane na adresy URL znajdują się w pliku test-servlet.xml. Jest to tak zwany WebapplicationContext zawierający tylko komponenty bean, które są wymagane głównie do obsługi żądań klientów.

Kolejną częścią jest warstwa Service/Dao, która składa się z logiki biznesowej. Fasole, które wykonują taką logikę, są ładowane w obiekcie ApplicationContext.

Teraz możesz zapytać, dlaczego rozdzielili te rzeczy na pliki lub dwa różne obiekty.

To dlatego, że aplikacja ma tę samą logikę biznesową, z której może korzystać wielu klientów pracujących na innym protokole. Możesz używać tych samych warstw usług do obsługi zarówno RMI, jak i połączeń HTTP. Tak więc Spring utworzył kontekst nadrzędny, który zaczął nas jako ApplicationContext. A następnie, jeśli twoja aplikacja obsługuje żądania sieciowe, możesz utworzyć serwlet dispathchera, który ma swój własny tekst aplikacji i jest inicjowany jako element potomny kontekstu nadrzędnego. Tak więc wszystkie komponenty potomne mogą być przywoływane w elemencie potomnym i mogą być zdominowane, ale nie odwrotnie.