Как уровень интеграции взаимодействует с уровнем бизнеса? - PullRequest
Новая
       30

Как уровень интеграции взаимодействует с уровнем бизнеса?

1 голос
/ 14 мая 2011

Мне нужен совет по разработке «уровня интеграции» системы N-Tiered на Java.Этот уровень отвечает за сохранение и получение данных для бизнес-уровня (расположенного на отдельном сервере).Я новичок в J2EE, и я прочитал несколько книг и блогов.Алфавитный набор технологических сокращений сбивает меня с толку, поэтому у меня есть несколько вопросов.

Первое, что у меня есть: я использую JPA (через Hibernate) для сохранения и извлечения данных в базу данных.Я сделал объекты доступа к данным объектами EJB и планирую развертывание на сервере приложений (JBoss), что упрощает транзакции (они находятся на уровне функций моих DAO), и мне не нужно беспокоиться о получении дескриптора к EntityManager (внедрение зависимости).Вот пример того, как это выглядит: 

@Entity
class A{
  @Id
  Long id;
  @OneToMany
  List<B> setOfBs = new ArrayList<B>;
}

@Entity
class B{
  @Id
  Long id;
}

@Remote
public interface ADAO{
  public A getAById(Long id);
}

@Stateless
class ADAOImpl implements ADAO{
  @PersistenceContext
  EntityManager em;

  public A getAById(Long id){ ... }
}

Мой вопрос: как бизнес-уровень должен обмениваться данными с уровнем интеграции.Я прочитал об услугах RESTful, и они кажутся достаточно простыми.Меня беспокоит производительность, когда частота получения и установки увеличивается (HTTP-связь не кажется особенно быстрой).Другой вариант - RMI.Мои DAO уже являются EJB.Могу ли я иметь бизнес-уровень доступа к ним напрямую (через JNDI)?Если так, что произойдет, если ссылка @OneToMany в приведенном выше примере загружается лениво?

Например, если бизнес-уровень выполняет что-то вроде следующего: 

Context context = new InitialContext(propertiesForIntegrationTierLookup);
ADAOImpl aDao = (ADAOImpl) context.lookup("something");
A myA = aDao.getAById(0);
int numberOfBs = myA.setOfBs.size();

Если список setOfBs загружается лениво, когда бизнес-уровень (на отдельном сервере) обращается к списку,размер правильный?Правильно ли загружается список с помощью магии EJB?Если нет (что я ожидаю), каково решение?

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

Ответы [ 2 ]

0 голосов
/ 06 июля 2014

Краткий ответ: Если вы используете подход «Интеграционный уровень», то вещи, которые вы должны интегрировать, должны быть слабо связанными сервисами, следуя принципам SOA.

Это означает, что вы не должны разрешать удаленные вызовы методов для объектов, которые могут выполнять вызовы инфраструктуры под крышкой на другом сервере. Если вы сделаете это, вы действительно создадите тесно связанное распределенное приложение, и вам придется беспокоиться о проблемах с отложенной загрузкой и масштабах контекста персистентности. Если вы хотите этого, вы можете рассмотреть расширенные контексты персистентности http://docs.jboss.org/ejb3/docs/tutorial/extended_pc/extended.html.

Вы говорили о «бизнес-уровне», но JPA не предоставляет бизнес-уровень. Он предоставляет сущности и разрешает операции CRUD, но обычно это не бизнес-операции. операция «RegisterUser» - это не просто вопрос сохранения сущности «пользователь». Уровень DAO может предлагать более высокий уровень работы, но DAO обычно используются для наложения тонкого слоя на базу данных, но он все еще ориентирован на данные.

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

Ваш бизнес-уровень должен вызывать сброс и обрабатывать любые исключения JPA и скрывать все это от вызывающей стороны.

Вопрос о том, как передавать ваши данные, остается. Во многих случаях параметры ваших запросов бизнес-сервисов будут аналогичны вашим сущностям JPA, но я думаю, вы заметите, что часто есть достаточные различия, которые вы хотите определить новые DTO. Например, бизнес-операция «RegisterUser» может обновить таблицу «User» и «EmailAddresses». Таблица «Пользователь» может содержать свойство «createDate», которое не является частью операции «RegisterUser», но имеет текущую дату.

Для создания DTO вы можете взглянуть на Project Lombok.

Чтобы скопировать DTO для сущности, вы можете использовать Apache Commons BeanUtils (например, PropertyUtils.copyProperties) для выполнения большой части работы, которая работает, если имена свойств совпадают.

Лично я не вижу смысла в XML в этом случае, если только вы не хотите полностью отделить ваши реализации.

0 голосов
/ 14 мая 2011

Когда вы вызываете size () для отложенной коллекции, он инициализируется, поэтому вы всегда получите правильный размер независимо от того, какой интерфейс вы используете - удаленный или локальный.

Другая ситуация, когда вы 'пытаемся использовать классы JPA в качестве объектов передачи данных (DTO) и запрашивать их через интерфейс Remote.Я не помню никаких проблем с отложенной инициализацией, потому что перед передачей все объекты должны быть сериализованы (с инициализированными отложенными коллекциями) на стороне сервера.В результате весь граф объектов передается по сети, что может привести к серьезным нагрузкам на процессор и сеть.Кроме того, чтобы десериализация была возможной, вам придется делиться классами JPA с удаленным приложением.И вот где и как заканчивается «волшебство EJB»:)

Итак, как только возможны удаленные вызовы, я бы предложил начать думать о стратегии передачи данных и объектах передачи данных не-JPA как о дополнительном слое данных.В моем случае я аннотировал классы DTO для привязки XML (JAXB) и повторно использовал их в веб-сервисах.

...