У меня есть объект домена с именем VehicleRecord, который является спящим объектом. Операции CRUD с этими VehicleRecords обрабатываются с помощью объекта доступа к объекту, реализованного в виде интерфейса сессионного компонента без сохранения состояния
@Local
interface VehicleRecordEao {
void add(VehicleRecord record);
List<VehicleRecord> findAll();
...
}
@Stateless
class HibernateVehicleRecordEaoBean implements VehicleRecordEao { ... }
С точки зрения бизнес-уровня удаление и добавление этих записей - это больше, чем просто операция CRUD. Например, могут быть требования к ведению журнала и безопасности. Для предоставления этих операций клиентам сессионные компоненты создаются на бизнес-уровне.
@Local
interface VehicleRecordManager {
void createVehicleRecord(VehicleRecord record);
List<VehicleRecord> findAll(String make, String model);
...
}
@Stateless
class VehicleRecordManagerBean {
public void createVehicleRecordManager(VehicleRecord record) {
//business rules such as logging, security,
// perhaps a required web service interaction
//add the new record with the Eao bean
}
...
}
Контроллеры работают между уровнем представления и указанным выше бизнес-уровнем, чтобы выполнить работу, преобразовывая между объектами представления (например, формами) и сущностями при необходимости.
Что-то здесь не так (пахнет). У меня есть класс Manager, который должен быть красным флагом, но несколько примеров в книгах по EJB фактически предлагают этот класс высокого уровня и склонны использовать менеджер имен сами. Я новичок в EJB-дизайне, но в OO-дизайне создаю классы высокого уровня, называемые Manager, Handler или Utility, и требует процедурного переосмысления.
Являются ли эти бины процедурного класса утилит обычным шаблоном, или плохо организовывать ваш сеанс с помощью группы методов, связанных только с сущностью, с которой они работают? Существуют ли соглашения по именованию для сессионных компонентов? Должны ли Eao и EJB-компоненты работать на одном уровне?
Если есть менее вонючая альтернатива этому шаблону, я бы хотел знать, спасибо.