Для чего нужны EJB

Question

В настоящее время я изучаю Jave-EE, имею большой опыт работы с C ++ и изучил Java SE. Я не понимаю цели Enterprise Java Beans; может кто-то уточнить это для меня. Меня не интересует устаревшее использование: это в контексте EJB-3.1 и Java-EE 6.

Кажется, что некоторые люди используют их, чтобы содержать бизнес-логику, для реализации бизнес-уровня традиционной 3-уровневой архитектуры. Это отделяет доменную логику от доменных объектов, что приводит к анемичной доменной модели . Но это идет вразрез со всеми моими инстинктами OOD; Я согласен с Мартином Фаулером, что это анти-паттерн . Должен ли я ослабить свои возражения против модели анемичной области? Или у EJB есть другое применение?

Answer 1

Как указано в нескольких других ответах, EJB идеально подходят для реализации уровня обслуживания.Это очень современный и легкий вид бобов в Java EE.Несмотря на название, вы не можете сравнить их с драконовскими тяжеловесными зверями EJB2, которые были в J2EE.Все согласны с тем, что те были катастрофой, но это уже не 2002 год.

С тех пор, как EJB3 (2006), EJB-бобы стали совершенной технологией.

Они помогают много здесь, предоставляя декларативные транзакции (каждый метод ввода автоматически запускает транзакцию, если она еще не выполняется, хотя это можно изменить при желании), пул, безопасность, блокировка, удаленное взаимодействие и затем некоторые.См. Следующие ответы для некоторых дополнительных деталей:

• Каркасы для многоуровневого многократного использования архитектур
• В каких ситуациях используются EJB?Требуются ли они при разработке веб-сайтов / веб-приложений?
• EJB 3 или Hibernate 3
• @ EJB-инъекция против поиска - проблема производительности

Транзакции были объяснены здесь, но добавим к этому: это не то, что нужно только для очень сложных, очень безопасных систем.Я бы сказал, что это базовое требование, даже когда речь идет только о базах данных.Если я обрабатываю простой заказ, я хочу, чтобы инвентарь и заказ обновлялись или оба не обновлялись вообще.Это так же просто, как наличие PK и FK в вашей базе данных для обеспечения целостности.

EJB упрощают управление транзакциями.Без EJB есть много стандартного кода для запуска, фиксации или отката tx.

Не следует также недооценивать преимущества объединения и заглушки, которые предоставляет EJB.Это означает, что в боб может быть введено много EJB-компонентов, и вам не нужно беспокоиться о том, что они создаются каждый раз, когда создается такой боб.В противном случае это было бы особенно проблематично, когда не все EJB-компоненты использовались бы каждый раз.

Из-за объединения, однако, вводятся только очень легкие заглушки, которые больше похожи на URL-адреса, которые указывают на фактический экземпляр.Они практически ничего не стоят с точки зрения затрат памяти или ресурсов процессора для внедрения.

EJB-компоненты также содержат аннотации для объявления их синглетонами, организации их поведения блокировки (блокировки записи / чтения), объявление о том, что их следует инициировать при запускеразрешить им управлять так называемым расширенным контекстом постоянства (контекстом постоянства, не ограниченным областью передачи) и т. д.

Это все проблемы, которые вам не нужны в ваших slim сущностях,Например, во многих архитектурах объект User представляет собой простой объект данных, который я хочу передавать по слоям.Я не хочу, чтобы мой экземпляр User имел метод sendMsg () и имел JMS-ресурс в качестве зависимости, так что отправка сообщения могла внезапно выполняться с какого-либо клиента.Я не совсем уверен, почему люди думают, что это как-то «естественно» и «ООП».

В реальном мире я также не вызываю операцию sendMsg для моего друга Джо, когда я хочу отправить ему открытку.Вместо этого я обращаюсь к карточке и доставляю ее в почтовое отделение или помещаю в почтовый ящик.

Я также не вызываю операцию bake () для торта.Вместо этого я ставлю торт в духовку и т. Д.

Answer 2

Использование Java EE не подразумевает автоматически анемичную модель предметной области, точно так же, как вы можете написать код, скажем, в Java, что не позволяет эффективно использовать лучшие практики, не означает, что это невозможно в Java.Я полагаю, что точка зрения Мартина Фаулера была на J2EE (обратите внимание на использование J2EE, а не Java EE) в значительной степени навязанную работу логики и данных.Использование объектов, основанных на POJO, позволяет соответствующим образом моделировать данные и поведение.«Бизнес-логика» в ваших EJB-компонентах обычно организует применение бизнес-логики, но чаще всего не выполняет ее на самом деле, обычно это очень тонкая оболочка.используемая платформа / фреймворк, вам нужно иметь что-то, что вы можете вызвать физически, это точка входа.Независимо от того, реализуете ли вы с помощью Spring, веб-сервисов и т. Д. Вам нужен сервисный уровень, ничто не мешает этому быть реализовано в Java EE.Довольно надуманный пример

@Stateless
public SomeServiceImpl implements SomeService
    someServiceMethod() {
       delegate.doSomething();
    }
}

public SomeServiceDelegate implements SomeService
    someServiceMethod() {
       modelObject.doSomething();
    }
}

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

Answer 3

Вы уже процитировали вариант использования "реализовать бизнес-логику".

EJB - в компонентных компонентах EJB 3.x, компонентах, управляемых сообщениями, и в 3.1 новые компоненты Singleton Bean действительно позволяют реализовать логику бизнес-процессов. Сессионные компоненты часто используются в качестве фасада, к которому подключаются клиенты. Такими клиентами могут быть сервлеты для обслуживания контента, например, через HTTP или также «толстые» клиенты, которые взаимодействуют с другими (более двоичными) протоколами с EJB.

Бины, управляемые сообщениями, служат конечной точкой асинхронной связи и могут, например, сами вызывать методы на Сессионных бинах.

У всех EJB есть одна общая черта, которая делает их очень привлекательными: ими управляет контейнер. Таким образом, контейнер заботится об инстанцировании, пуле, транзакциях, безопасности и т. Д.

Если вы пишете в EJB

@Resource DataSource x;

Контейнер гарантирует, что когда ваш компонент готов к приему вызовов методов, переменная 'x' содержит подходящий источник данных.

Объединение в пул Beans позволяет подключить к сайту гораздо больше клиентов, чем вы могли бы обойтись без этого, так как либо экземпляры являются общими (SB без сохранения состояния), либо экземпляры могут быть выгружены контейнером во вторичное хранилище, если не хватает памяти и активировать их позже.

В EJB 3 старые EntityBeans из EJB 1.x и 2.x ушли и заменены на JPA, который создает модель данных домена POJO, которая может быть либо аннотирована для обеспечения реляционной семантики, либо семантика может быть предоставляется внешними файлами XML.

С JPA (который вообще не требует EJB), EJB часто служат для реализации обработки этих объектов:

@Stateless
public class MyBean {
    @PersistenceContext EntityManager em;

    public Foo getFoo(String name) {
        Query q = em.createQuery("SELECT f FROM Foo f WHERE f.name = :name");
        q.setParameter("name",name);
        return q.getSingleValue();
    }
}

Answer 4

Пара моментов:

• EJB не существуют сами по себе;они живут в контейнере EJB, который через них предлагает вам несколько очень полезных сервисов, таких как декларативная безопасность, декларативные транзакции и относительно простая кластеризация.
• Хотя модели анемичного домена действительно являются антипаттерном: однажды ваша бизнес-логикастановится более сложным, например, когда несколько приложений работают на одной модели, отделение большей части логики от модели становится вопросом разделения интересов.

Answer 5

Просто замечание из личного опыта ...

Я не сомневаюсь в преимуществах EJB, но, поработав с ними, я вижу, что EJB подходят только в тех случаях, когда безопасность и транзакции очень важны (например, финансовые приложения). В 90% случаев вы бы прекрасно работали без EJB. Другое дело ... масштабируемость и EJB не являются хорошими друзьями.

Answer 6

Некоторые ребята рассказывают в обсуждении, как это, EJB стал полезным в EJB3 не раньше этого, и это не так.Да, он стал более мощным, особенно с JPA, но EJB1.0 и EJB2.1 все же многое сделали.возможно, они не использовали его в больших приложениях, поэтому говорят, что.

, например, POJO не может иметь дело с транзакцией, поэтому в EJB вы можете указать тип транзакции для конкретного метода, если он требует новоготранзакция или не из транзакции.

в моей организации мы используем сборку ERP с нуля и используем EJB в бизнес-логике, он был с 2000 года, а EJB был версии 1.0.и он не только отделяет бизнес-уровень от других, но также отделяет систему друг от друга, например: финансовый модуль отделен от HR-модуля.и если они хотят добавить новый модуль, они могут добавить его, не перезапуская систему, и он будет идеально интегрироваться с системой ..

и запомнит это в EJB: то, что вы видите в коде, - ничтои то, что EJB-контейнер делает для вас - это все :).

Answer 7

апатриды-и-сохраняющие состояние-предприятия-ява-бобы

EJB-апатриды-сессия-бобы-и-Stateful-сессия боб