Когда это необходимо или удобно использовать Spring или EJB3 или все вместе?

Меня немного смущает смешанное использование JSF2 + Spring + EJB3 или любая их комбинация. Я знаю, что одна из основных характеристик Spring - это инъекция зависимостей, но с управляемым JSF beans я могу использовать аномалии @ManagedBean и @ManagedProperty, и я получаю функциональность впрыска зависимостей. С EJB3 я еще больше смущен, когда его использовать вместе с JSF или если есть даже причина использовать его.

Итак, в какой ситуации было бы хорошей идеей использовать Spring + JSF2 или EJB3 + JSF2?

До сих пор я создал несколько небольших веб-приложений, использующих только JSF2 и никогда не нуждающихся в использовании Spring или EJB3. Тем не менее, я вижу во многих местах, что люди работают со всем этим вместе.

Ответ 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-шаблон (но по существу не представляет собой уровень бизнес-сервиса в целом).

См. также:

Ответ 2

Здесь нет реального легкого ответа, поскольку Spring - это много вещей.

На действительно высоком уровне Spring конкурирует с Java EE, что означает, что вы использовали бы одну из них в качестве полной структуры стека.

На более мелкозернистом уровне контейнер Spring IoC и Spring Beans конкурируют с комбинацией CDI и EJB в Java EE.

Что касается веб-уровня, Spring MVC конкурирует с JSF. Некоторые Spring xyzTemplate конкурируют с интерфейсами JPA (оба могут использовать, например, Hibernate как их реализацию).

Можно смешивать и сопоставлять; например, используйте CDI и EJB Beans с Spring MVC, или используйте Spring Beans с JSF.

Обычно вы не будете использовать 2 конкурирующих друг друга. Spring Beans + CDI + EJB в том же приложении, или Spring MVC + JSF глупо.