Разделение презентаций и бизнес-уровней с Spring

Question

В моем только что завершенном проекте я работал, чтобы работали распределенные транзакции.

Мы реализовали это с помощью диспетчера транзакций Arjuna от JBoss и декларативных границ транзакций Spring.

Наша последовательность запросов выглядела так:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

Это означало, что у нас была WAR для обслуживания нашего защищенного сервлета и EAR для обслуживания SLSB.

Наш SLSB имел статический блок инициализации для начальной загрузки контекста нашего приложения Spring.

Мне не нравится сочетание технологий, но мне нравится разделять уровни представления и бизнес-уровня, которые могут находиться в разных физических местах.

Мне было бы интересно узнать, что другие предлагают разделить уровни при использовании Spring?

Answer 1

Довольно типичным подходом является определение веб-уровня, уровня службы и уровня DAO и привязка транзакционной семантики к уровню службы. Например, сервисным уровнем может быть группа POJO с аннотациями @Transactional. Веб-уровень может быть контроллерами Spring Web MVC. При таком подходе веб-уровень по существу адаптирует уровень службы к HTTP. Хорошее разделение и нет необходимости в SLSB здесь.

Тем не менее, одна из областей обсуждения - это доменные объекты, такие как Employee или PurchaseOrder или что-то еще. Эти уровни охвата приложений и одна вещь, которая, кажется, происходит с аннотациями, состоит в том, что доменные объекты получают аннотации, которые привязаны к определенным уровням. Таким образом, вы можете использовать аннотации ORM здесь, но затем использовать тот же объект домена, что и компонент поддержки формы, чтобы избежать параллельных классов объектов домена / формы. Некоторые люди возражают против этого как за нарушение архитектурного разделения интересов.

Answer 2

Требование сервера приложений EJB3 только для SLSB, который является фасадом, не кажется мне стоящим усилий. Нет причины, по которой вы не могли бы просто удалить это и заставить свой сервлет работать напрямую с Spring. Вы можете добавить ContextLoaderListener в WAR, чтобы загрузить ApplicationContext, а затем WebApplicationContextUtils, чтобы получить его. В качестве альтернативы вы можете использовать SpringMVC, Struts или другие веб-технологии, если вам нужно сделать больше, чем позволяет сам сервлет.