Миграция с EJB3 на Spring, Hibernate - PullRequest
Новая
       27

Миграция с EJB3 на Spring, Hibernate

6 голосов
/ 02 июня 2011

У нас есть настольное приложение на базе EJB3, Oracle 10 и JBoss 4. Оно было создано около трех лет назад. Сущности JPA использовались для ORM, а бизнес-логика была реализована в компонентах Sessionless. Клиент был разработан с использованием Swing API.

Теперь существует требование заменить предыдущую технологию на Spring, Hibernate и JBoss для следующего выпуска приложения. Клиент все еще будет в Swing. План состоит в том, чтобы заменить сущности на POJO и поместить бизнес-логику из Session Beans в Spring Beans, то есть объекты доступа к данным (которые расширяют HibernateDaoSupport).

Итак, вопрос в том, возможно ли, что мы полностью освободим наше приложение от Session Beans и перенесем бизнес-логику в Spring Dao? Или нам все еще нужно сохранять сессионные компоненты? Если сессионных компонентов полностью избежать, как клиентское приложение сможет получить доступ к бизнес-методам? Как и в случае приложения на основе JavaEE, сессионные компоненты были доступны через поиск Jndi.

Любые предложения приветствуются.

Ответы [ 3 ]

8 голосов
/ 03 июня 2011

Если вы переносите прекрасно работающее приложение EJB3 / JPA в Spring / Hibernate только потому, что вы думаете , конечный результат будет более легким, то ИМХО вы делаете это по неправильным причинам и можете смотреть на тратить огромное количество инженерных усилий.

Spring и EJB3 довольно похожи. Spring исторически был более тяжеловесным в отделе XML, но теперь он более точно следует подходу, основанному на аннотациях EJB3. В общем, эти двое, похоже, участвуют в конкурсе кроликов. Иногда Spring вводит новшества и на шаг впереди, но затем EJB3 вводит новшества и снова на шаг впереди. Оба постоянно основывают свои особенности на функциях другого.

Вместо перехода на Spring я бы предложил обновить ваш сервер с JBoss AS 4 до 6, или, если вы можете терпеть ожидание, подождите пару месяцев и переходите к JBoss AS 7.

P.s. Если у вас уже было отлично работающее Spring-приложение, я бы не советовал переходить на EJB3 только для того, чтобы стать более легким.

7 голосов
/ 02 июня 2011

Это вполне возможно, на самом деле эти технологии ничем не отличаются.Чтобы сразу начать, попробуйте это: 

<context:component-scan
        base-package="com.example.project"
        scope-resolver="org.springframework.context.annotation.Jsr330ScopeMetadataResolver">
    <context:include-filter type="annotation" expression="javax.ejb.Stateless"/>
</context:component-scan>

Snap!Теперь все ваши SLSB теперь являются прототипом Spring bean.Если некоторые SLSB имеют состояние (дух!), Вам нужно будет обернуть их в объединяющий прокси, и многое еще предстоит сделать.Но Spring уже поддерживает большинство функций EE.Например, на начальном этапе с JPA и Hibernate backend - никаких изменений в коде DAO не требуется, @EntityManger может быть введен таким же образом в bean-компоненты Spring.

Также тем временем вы можете смешивать Spring и EJB -EJB-компоненты могут быть легко внедрены в бины Spring, обеспечивая хорошую совместимость.

UPDATE : Кроме того, почему вы хотите " downgrade " из JPA do Hibernate?Если ваше приложение отлично работает с JPA, используйте его и в приложении Spring - и когда вам нужны особые функции Hibernate, вы все равно можете использовать их время от времени.

5 голосов
/ 02 июня 2011

Spring bean-компоненты не только "DAO", вы также можете иметь "службы" для реализации бизнес-логики (см. http://biese.wordpress.com/2007/10/08/service-layer-and-dao-architecture/).

Службы будут внедряться в зависимости на уровне представления. Если вам нужен RMI между уровнем представления и бизнес-уровнем, вы должны использовать Spring Remoting http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html (с RMI).

...