Когда необходимо или удобно использовать Spring или EJB3 или все вместе?
Меня немного смущает смешанное использование JSF2+Spring+EJB3 или любой их комбинации. Я знаю, что одной из основных характеристик Spring является внедрение зависимостей, но с управляемыми компонентами JSF я могу использовать @ManagedBean а также @ManagedProperty аннотации и я получаю функциональность внедрения зависимости. С EJB3 меня еще больше смущает вопрос, когда использовать его вместе с JSF или есть ли причина для его использования.
Итак, в какой ситуации будет хорошей идеей использовать Spring+JSF2 или EJB3+JSF2?
До сих пор я создал только несколько небольших веб-приложений, использующих только JSF2, и мне никогда не приходилось использовать Spring или EJB3. Тем не менее, я вижу во многих местах, что люди работают со всем этим вместе.
2 ответа
Прежде всего, Spring и EJB(+JTA) являются конкурирующими технологиями и обычно не должны использоваться вместе в одном приложении. Выберите один или другой. Spring или EJB(+JTA). Я не скажу вам, какой выбрать, я расскажу вам немного истории и фактов, чтобы вам было легче принять решение.
Основная проблема, которую они пытаются решить, - это предоставление API уровня бизнес-сервисов с автоматическим управлением транзакциями. Представьте, что вам нужно запустить несколько SQL-запросов для выполнения одной бизнес-задачи (например, разместить заказ), и один из них не выполнен, тогда вам, конечно, хотелось бы, чтобы все откатывалось, чтобы БД оставалась в том же состоянии. как и раньше, как будто ничего не произошло. Если вы не используете транзакции, то БД останется в недопустимом состоянии, потому что первая группа запросов действительно выполнена успешно.
Если вы знакомы с базовым JDBC, вы должны знать, что этого можно достичь, отключив автокоммит соединения, затем последовательно выполнив эти запросы, затем выполнив commit() в том же самом try в чьей catch (SQLException) rollback() выполняется. Это, однако, довольно утомительно для реализации каждый раз.
В Spring и EJB(+JTA) один вызов метода бизнес-службы без сохранения состояния по умолчанию считается прозрачным как одна полная транзакция. Таким образом, вам не нужно беспокоиться об управлении транзакциями вообще. Вам не нужно создавать вручную EntityManagerFactory, ни явно em.getTransaction().begin() и то, что вы делаете, когда вы тесно связываете логику бизнес-сервисов с классом бина 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 и вызвать orderService.placeOrder(newOrder); в методе действия будет выполнена одна полная транзакция. Если, например, один из updateQuantity() звонки или persist() вызов не выполнен с исключением, тогда он выполнит откат любого выполненного до сих пор updateQuantity() звонки, и оставить БД в чистом и четком состоянии. Конечно, вы можете перехватить это исключение в компоненте поддержки JSF и отобразить сообщение лиц или около того.
Следует отметить, что "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, который предлагает новый EJB3 API, который даже более изящен, чем Spring, и вообще не требует XML.
Spring также предлагает IoC/DI (инверсия управления; внедрение зависимостей) из коробки. Это было в эпоху J2EE, сконфигурированной с помощью XML, что может оказаться слишком сложным. В настоящее время Spring также использует аннотации, но все же требуется некоторый XML. Начиная с Java EE 6, после изучения уроков из Spring, CDI предлагается из коробки для обеспечения той же функциональности DI, но затем без какой-либо необходимости в XML. С весны DI @Component/@Autowired и CDI @Named/@Inject вы можете достичь того же, что и JSF @ManagedBean/@ManagedPropertyНо Spring DI и CDI предлагают гораздо больше преимуществ: вы можете, например, записывать перехватчики для создания / уничтожения управляемого или постобработанного управляемого компонента или вызова метода управляемого компонента, вы можете создавать собственные области действия, производителей и потребителей, вы может внедрить экземпляр более узкой области в случае более широкой области и т. д.
Spring также предлагает MVC, который по сути конкурирует с JSF. Нет смысла смешивать JSF с Spring MVC. Кроме того, Spring также предлагает Data, который, по сути, является дополнительным уровнем абстракции по сравнению с JPA, еще больше минимизируя шаблон DAO (но который по существу не представляет уровень бизнес-сервисов в целом).
Смотрите также:
Здесь нет простого ответа, потому что весна - это много вещей.
На самом высоком уровне Spring конкурирует с Java EE, что означает, что вы будете использовать любой из них в качестве среды полного стека.
На более детальном уровне контейнер Spring IoC и Spring Beans конкурируют за сочетание CDI и EJB в Java EE.
Что касается веб-слоя, Spring MVC конкурирует с JSF. Некоторые Spring xyzTemplate конкурируют с интерфейсами JPA (оба могут использовать, например, Hibernate в качестве их реализации).
Можно смешивать и сочетать; например, используйте bean-компоненты CDI & EJB с Spring MVC, ИЛИ используйте bean-компоненты Spring с JSF.
Обычно вы не будете использовать двух напрямую конкурирующих технологий. Spring бобы + CDI + EJB в том же приложении, или Spring MVC + JSF глупо.