Ответ 1
Прежде всего, Spring и EJB (+ JTA) являются конкурирующими технологиями и обычно не должны использоваться вместе в одном приложении. Выберите тот или другой. Spring или EJB (+ JTA). Я не скажу вам, что выбрать, я расскажу вам немного истории и фактов, чтобы вы могли легче принять решение.
Основной проблемой, которую они пытаются решить, является предоставление API уровня бизнес-сервиса с автоматическим управлением транзакциями. Представьте себе, что вам нужно запустить несколько SQL-запросов для выполнения одной бизнес-задачи (например, размещение заказа), и один из них не прошел, тогда вам, конечно же, понравится, что все откатывается, так что БД хранится в одном состоянии как это было раньше, как будто ничего не произошло. Если вы не использовали транзакции, тогда БД останется в недопустимом состоянии, потому что первая группа запросов действительно преуспела.
Если вы знакомы с базовым JDBC, то вы должны знать, что этого можно добиться, отключив автосообщение в соединении, затем последовательно выполнив эти запросы, а затем выполнив commit() в том же try, в catch (SQLException) a rollback(). Это, однако, довольно утомительно для реализации каждый раз.
С помощью Spring и EJB (+ JTA) однопользовательский вызов службы бизнес-службы по умолчанию считается прозрачным как одна полная транзакция. Таким образом, вам не нужно беспокоиться об управлении транзакциями. Вам не нужно вручную создавать EntityManagerFactory или явно вызывать em.getTransaction().begin() и, например, делать это, когда вы применяете логику бизнес-обслуживания с жесткой связью в класс поддержки bean JSF и/или используете RESOURCE_LOCAL вместо этого JTA в JPA. Например, у вас может быть только следующий класс EJB с использованием JPA:
@Stateless
public class OrderService {
@PersistenceContext
private EntityManager em;
@EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
Если у вас есть @EJB private OrderService orderService; в вашей поддержке JSF bean и вызовите orderService.placeOrder(newOrder); в методе действий, то будет выполнена одна полная транзакция. Если, например, один из вызовов updateQuantity() или вызов persist() завершился с исключением, тогда он откатит любые выполненные до сих пор вызовы updateQuantity() и оставьте БД в чистом и четком состоянии. Конечно, вы можете поймать это исключение в своей поддержке JSF bean и отобразить сообщение с лицами или так.
Отмечается, что "Spring" - довольно большая структура, которая не только конкурирует с EJB, но и CDI и JPA. Раньше, во время темных возрастов J2EE, когда EJB 2.x был чрезвычайно ужасен для реализации (приведенный выше пример EJB 3.x OrderService в EJB 2.x потребовал бы как минимум в 5 раз больше кода и некоторого XML-кода). Spring предложила гораздо лучшую альтернативу, которая требовала меньше кода Java (но все еще много XML-кода). J2EE/EJB2 выучил уроки из Spring и пришел с Java EE 5, который предлагает новый API EJB3, который еще более гладкий, чем Spring и вообще не требует XML.
Spring также предлагает IoC/DI (инверсия управления, инъекция зависимостей) из коробки. Это было во время эры J2EE, настроенной XML, которая может пойти довольно за борт. В настоящее время Spring также использует аннотации, но требуется некоторый XML. Начиная с Java EE 6, после изучения уроков из Spring, CDI предлагается в блоке для предоставления одинаковых функциональных возможностей DI, но без необходимости XML. С Spring DI @Component/@Autowired и CDI @Named/@Inject вы можете добиться того же, что и JSF с помощью @ManagedBean/@ManagedProperty, но Spring DI и CDI предлагает гораздо больше преимуществ вокруг это: вы можете, например, написать перехватчики для предварительного или последующего управления управляемым вызовом bean create/destroy или управляемого bean, вы можете создавать собственные области, производителей и потребителей, вы можете ввести экземпляр более узкой области видимости в случае более широкого охвата и т.д.
Spring также предлагает MVC, который по существу конкурирует с JSF. Не имеет смысла смешивать JSF с Spring MVC. Далее Spring также предлагает данные, которые по существу являются дополнительным уровнем абстракции над JPA, что еще больше минимизирует DAO-шаблон (но по существу не представляет собой уровень бизнес-сервиса в целом).