Java, настройте корпоративное приложение и веб-приложение с помощью Spring: должны ли они использовать контекст Spring? - PullRequest
Новая
       8

Java, настройте корпоративное приложение и веб-приложение с помощью Spring: должны ли они использовать контекст Spring?

0 голосов
/ 03 октября 2011

У меня есть приложение на основе событий, основанное на Spring-интеграции. Приложение состоит из 4 модулей: домен (объекты модели), персистентность (daos), ядро ​​(бизнес-логика на основе Spring-интеграции) (MDB).

Каждый модуль - это проект Maven. Приложение упаковано в EAR и развернуто на weblogic.

Контекст весны является общим для всех модулей.

Теперь мне нужно разработать веб-приложение для отображения подмножества домена: поэтому мои контроллеры должны использовать некоторые daos и некоторые объекты домена. Как лучше всего справиться с этой проблемой? Должно ли веб-приложение совместно использовать весь контекст «Ушная весна»? Или лучше создать «пружинный» контекст веб-приложения, в котором я переопределяю все, что мне нужно? (например, Daos).

Ответы [ 2 ]

1 голос
/ 03 октября 2011

Похоже, что вы выиграете от функционального слоя, например, instead of 

|- persistence (daos)
|- domain (model objects)
|- core (biz logic based on spring-integration)
|- services (MDB)

Вы можете функционально распределить свое приложение по слоям.Допустим, ваше приложение торгует: 

|- broker
|- product
    |- underlying
    |- option
    |- future
    |- forward
    |- ..
|- feed 
|- valuation
|- ...

При broker у вас будет broker-persistence, broker-service и т. Д. Конечно, сфера бизнеса вашего приложения, вероятно, иная, и этоНаивный пример, но он иллюстрирует суть.

Таким образом, вы все равно можете включить все в свой EAR, с гораздо большей гибкостью в отношении того, что может быть включено / импортировано в ваше веб-приложение.

Например, вы даже можете создать broker.war отдельно от product.war.Что также означает, что вы можете перераспределить a broker.war без сброса product.war.Возможно, он вам не понадобится в вашем бизнес-домене, но это хорошая возможность, которую можно получить, только если все наслоено в соответствии с бизнес-потребностями / областью, а не технологическим стеком.

Кстати, не нужно усложнять ситуацию с EAR только для MDB, вы можете использовать POJO, управляемые сообщениями Spring *, которые будут просто управляться контейнером Spring.

0 голосов
/ 03 октября 2011

Обычно вы создаете определенный WebApplicationContext для каждого DispatcherServlet , в который вы помещаете все связанные с вебом материалы, например, контроллеры, сопоставление обработчиков, средства просмотра и т. Д. Остальные контексты вашего приложения, например сервисы, daosи т. д. настроены / настроены в корневом WebApplicationContext , который используется всеми сервлетами.

Пример web.xml : 

<web-app ...>

    <!-- Definition of the root web application context and shared by all servlets -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/dao-config.xml,/WEB-INF/other-config.xml</param-value>
    </context-param>

    <!-- Must be added to enable the configs above -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <!-- Servlet specific application context that inherits bean definitions from the root application context. By convention, it is located in in /WEB-INF/[servlet-name]-servlet.xml -->
    <servlet>
        <servlet-name>yourservlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

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

</web-app>

Прокрутите вниз до рисунка «Иерархия контекста в Spring Web MVC» в Справочной документации Spring MVC для обзора и получения дополнительной информации.

...