ligrimp Mar 29 2010 at 07:12

Будущее построения архитектуры Java EE приложений становится яснее

1 min

3.6K

Java*

Translation

Comments 12

PATRICK17 Mar 29 2010 at 09:40

ну и здорово!

braindamaged Mar 29 2010 at 10:38

Уважаю SpringSource, очень влиятельные ребята

djko Mar 29 2010 at 11:34

Поправьте не «Spring 6» а «Spring 3», а то я уж было подумал что что пропустил пару релизов:)

ligrimp Mar 29 2010 at 11:37

fixed

whtiger Mar 29 2010 at 11:54

Расскажите, пожалуйста, через что вы используете Spring ORM? Как я понимаю там есть выбор из hibernate, jpa, jdo.

whtiger Mar 29 2010 at 11:55

Забыл написать, что я использую jpa.

ligrimp Mar 29 2010 at 12:04

Spring предоставляет удобные оболочки над технологиями Jpa, JDO, Hibernate, iBatis и jdbc. Эти оболочки позволяют и удобнее, единообразно, разботать с различными orm/dao ресурсами, а также управлять доступом к ним в spring-way транзакциях.

ligrimp Mar 29 2010 at 12:05

В догонку — я в общем то работал с каждой из этих оболочек.

whtiger Mar 29 2010 at 12:39

Это я к тому спрашиваю, что JPA это в общем-то часть JavaEE. И мне было бы интересно узнать какая другая технология, по вашему мнению, более удобна.

ligrimp Mar 29 2010 at 12:43

В статье речь шла о выборе сервисного слоя, а не orm технологий. Ничего не мешает использовать JPA как в связке со спрингом, так и EJB. В принципе сейчас JPS 2.0 по функционалу догнал Hibernate, так что выбор определяется конкреной задачей.

whtiger Mar 29 2010 at 13:37

Просто вы написали, что «не эти технологии вместе», а JPA — часть JavaEE.

ligrimp Mar 29 2010 at 13:42

А выше было объяснение: если берем связку javaee компонентов и спринга, то для серьезных проектов необходимо покупать поддержку как вендора jvaee так и спрингсорс. Но, т.к. javaee приблизился по функционалу к своим «свободным» конкурентам, то делать это в общем то бессмысленно и невыгодно.

Show the best of all time