Какое использование EJB

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

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

Ответ 1

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

EJB, таким образом, образуют ваш API-интерфейс Service Service, вам нужна эта платформа, которую вы используете, вам нужно иметь что-то, что вы можете физически вызывать, это точка входа. Вне зависимости от того, используете ли вы spring, веб-сервисы и т.д. Вам нужен уровень сервиса, в Java EE ничего не прекращается. Пример довольно надуманный

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

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

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

Ответ 2

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

С тех пор, как EJB3 (2006), EJB beans были отличной технологией.

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

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

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

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

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

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

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

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

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

Ответ 3

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

EJBs - в EJB 3.x Session Beans, Message Driven Beans, а в 3.1 новый Singleton Beans действительно позволяет реализовать логику biz. Сессия Beans часто используется как фасад, к которому подключаются клиенты. Этими клиентами могут быть Servlets для обслуживания контента через, например, HTTP или также "толстых" клиентов, которые разговаривают с другими (более бинарными) протоколами с EJB.

Message Driven Beans служит в качестве конечной точки асинхронной связи и сам может вызывать методы на сеансе Beans в качестве примера.

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

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

@Resource DataSource x;

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

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

В 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();
    }
}

Ответ 4

Несколько пунктов:

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

stateless-and-stateful-enterprise-java-beans

ejb-stateless-session-beans-and-stateful-session-bean