Для чего нужны EJB
В настоящее время я изучаю Jave-EE, имею большой опыт работы с C++ и изучаю Java SE. Я не понимаю цели Enterprise Java Beans; может кто-то уточнить это для меня. Меня не интересуют устаревшие применения: это в контексте EJB-3.1 и Java-EE 6.
Кажется, что некоторые люди используют их, чтобы содержать бизнес-логику, для реализации бизнес-уровня традиционной 3-уровневой архитектуры. Это отделяет доменную логику от доменных объектов, что приводит к анемичной модели домена. Но это идет вразрез со всеми моими инстинктами OOD; Я согласен с Мартином Фаулером, что это анти-паттерн. Должен ли я ослабить свои возражения против модели анемичной области? Или у EJB есть другое применение?
7 ответов
Использование Java EE не подразумевает автоматически анемичную модель предметной области, точно так же, как вы можете писать код, скажем, в Java, что не позволяет эффективно использовать лучшие практики, не означает, что это невозможно в Java. Я полагаю, что точка зрения Мартина Фаулера была J2EE (обратите внимание на использование J2EE, а не Java EE) в значительной степени навязанную работу логики и данных. Использование объектов, основанных на POJO, позволяет соответствующим образом моделировать данные и поведение. "Бизнес-логика" в ваших EJB-компонентах обычно управляет применением бизнес-логики, но чаще всего фактически не выполняет ее, обычно это очень тонкая оболочка.
EJB-компоненты, таким образом, формируют ваш Service API, вам нужна эта платформа / фреймворк, который вы используете, вам нужно иметь что-то, что вы можете вызвать физически, это точка входа. Независимо от того, реализуете ли вы Spring, веб-сервисы и т. Д. Вам нужен сервисный уровень, ничто не мешает этому реализоваться в Java EE. Довольно надуманный пример
@Stateless
public SomeServiceImpl implements SomeService
someServiceMethod() {
delegate.doSomething();
}
}
public SomeServiceDelegate implements SomeService
someServiceMethod() {
modelObject.doSomething();
}
}
Я не буду вдаваться в причины предпочитать EJB-компоненты другим технологиям, просто хочу указать, что их использование не означает, что ваша реализация не может использовать передовой опыт.
Как указано в нескольких других ответах, 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-компоненты также содержат аннотации, объявляющие их синглетонами, упорядочивают их поведение при блокировке (блокировки записи / блокировки чтения), объявляя, что их следует инициировать при запуске, позволяя им управлять так называемым расширенным контекстом персистентности (контекст персистентности, не ограниченный областью передачи).), так далее.
Это все проблемы, которые вам не нужны в ваших тонких сущностях. Например, во многих архитектурах объект User - это простой объект данных, который я хочу передавать по слоям. Я не хочу, чтобы мой экземпляр User имел метод sendMsg() и имел JMS-ресурс в качестве зависимости, так что отправка сообщения могла внезапно выполняться с какого-либо клиента. Я не совсем уверен, почему люди думают, что это как-то "естественно" и "ООП".
В реальном мире я также не вызываю операцию sendMsg для моего друга Джо, когда я хочу отправить ему открытку. Вместо этого я обращаюсь к карточке и доставляю ее в почтовое отделение или помещаю в почтовый ящик.
Я также не вызываю операцию bake() для торта. Вместо этого я ставлю торт в духовку и т. Д.
Вы уже процитировали вариант использования "реализовать бизнес-логику".
EJB - в EJB 3.x Session Bean, Message Driven Beans и в 3.1 новые Singleton Beans действительно позволяют реализовать логику бизнеса. Сессионные компоненты часто используются в качестве фасада, к которому подключаются клиенты. Эти клиенты могут быть сервлетами для обслуживания контента, например, через 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();
}
}
Пара моментов:
- EJB не существуют сами по себе; они живут в контейнере EJB, который предлагает вам несколько очень полезных сервисов, таких как декларативная безопасность, декларативные транзакции и относительно простая кластеризация.
- Хотя модели анемичной области действительно являются антипаттерном: если ваша бизнес-логика становится более сложной, например, когда несколько приложений работают на одной и той же модели, отделение большей части логики от модели становится вопросом разделения интересов.
Просто замечание из личного опыта...
Я не сомневаюсь в преимуществах EJB, но, поработав с ними, я вижу, что EJB подходят только в тех случаях, когда безопасность и транзакции очень важны (например, финансовые приложения). В 90% случаев вы бы прекрасно работали без EJB. Другое дело... масштабируемость и EJB не являются хорошими друзьями.
Некоторые парни рассказывают, что в обсуждении EJB стал полезным в EJB3 не раньше, и это не так. Да, он стал более мощным, особенно с JPA, но EJB1.0 и EJB2.1 все же многое сделали. возможно, они не использовали его в больших приложениях, поэтому они так говорят.
например, POJO не может иметь дело с транзакцией, поэтому в EJB вы можете указать тип транзакции для определенного метода, если она требует новой транзакции или не из транзакции.
в моей организации ERP-сборка была построена с нуля, и мы использовали EJB в бизнес-логике, это было с 2000 года, а EJB был версией 1.0. и он не только отделяет бизнес-уровень от других, но также отделяет систему друг от друга, например: финансовый модуль отделен от HR-модуля. и если они хотят добавить новый модуль, они могут добавить его без перезапуска системы, и он будет идеально интегрироваться с системой..
и запомните это в EJB: то, что вы видите в коде, - ничто, а то, что EJB-контейнер делает для вас, - это все:) .