Как Spring управляет своими зависимостями в Spring mvc

Question

Как контекст приложения Spring работает внутри контейнера Tomcat или любого другого контейнера. Как он сохраняет внедренные bean-компоненты для каждого запроса, как после создания bean-компонента, он никогда не создает его снова. Как это поддерживает эти зависимости? Поддерживает ли он эти автоматические компоненты в serveltcontext, поскольку он инициализируется только один раз? Как Spring получает контроль над всем веб-приложением при настройке DispacherServlet? Я знаю, как это работает в универсальном приложении с использованием функции main, я хотел бы понять это с точки зрения веб-приложения?

Answer 1

Весенним бобом по умолчанию считается синглетон. Так что бин синглтоне весной - это действительно один объект на контейнер IOC. Фактически все веб-ресурсы поддерживаются в webApplicationContext.

WebApplicationContext является расширением простого ApplicationContext, который имеет некоторые дополнительные функции, необходимые для веб-приложений. WebApplicationContext привязан к вашему ServletContext .

Весной mvc, когда вы определяете что-то вроде ниже:

<web-app>

    <servlet>
        <servlet-name>golfing</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>golfing</servlet-name>
        <url-pattern>/golfing/*</url-pattern>
    </servlet-mapping>

</web-app>

На мгновение, если вы забыли, что используете Spring, это фактически определение сервлета в web.xml.

После того, как вы настроили DispatcherServlet и поступил запрос для этого конкретного DispatcherServlet, DispatcherServlet начинает обрабатывать запрос следующим образом:

1. WebApplicationContext ищется и связывается в запросе как атрибут, который контроллер и другие элементы процесса могут использовать. По умолчанию он связан с ключом DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
2. Средство распознавания языковых стандартов привязано к запросу, чтобы разрешить элементам процесса разрешать языковой стандарт, используемый при обработке запроса (отображение, подготовка данных и т. Д.). Если вам не нужно разрешение локали, оно вам не нужно.
3. Средство разрешения тем связано с запросом, чтобы элементы, такие как представления, определяли, какую тему использовать. Если вы не используете темы, вы можете игнорировать их.
4. Если вы укажете многочастный преобразователь файлов, запрос проверяется на наличие множественных частей; если найдены множественные части, запрос помещается в MultipartHttpServletRequest для дальнейшей обработки другими элементами в процессе
5. Поиск соответствующего обработчика. Если обработчик найден, цепочка выполнения, связанная с обработчиком (препроцессоры, постпроцессоры и контроллеры), выполняется для подготовки модели или рендеринга.
6. Если модель возвращается, представление отображается. Если модель не возвращается (может быть из-за того, что препроцессор или постпроцессор перехватил запрос, возможно, по соображениям безопасности), представление не отображается, поскольку запрос уже мог быть выполнен.

У Spring очень хорошая документация. Вы должны прочитать это, чтобы понять поток. Spring-mvc doc