EJB3: Почему семантика транзакций и отслеживание состояния рассматриваются как детали реализации? - PullRequest
Новая
       26

EJB3: Почему семантика транзакций и отслеживание состояния рассматриваются как детали реализации?

1 голос
/ 25 января 2010

Семантика транзакций и полнота состояния считаются деталями реализации в EJB3. Реализация может решить, использовать ли управляемые компонентом или контейнером транзакции. Он может решить тип управляемой контейнером транзакции. Он может решить, является ли он полным или без состояния.

Однако, по логике, это важные детали интерфейса. Примеры: (a) Бин, использующий транзакции, управляемые бином, не может вызвать бин, использующий транзакции, управляемые контейнером. (b) Компонент без состояния не может вызывать компонент с полным состоянием.

При представлении интерфейса EJB3 вы не представляете, какая семантика транзакции требуется Точно так же вы понятия не имеете, полное это состояние или нет. Вам нужны дополнительные детали реализации. Пример: документация.

Во время выполнения различные компоненты и цепочки вызовов могут быть созданы динамически. Таким образом, может возникнуть недопустимое состояние. Теперь - контейнер может ловить эти ситуации; но зачем ждать до времени выполнения?

Почему семантика транзакций и требования к полноте состояния не являются частью интерфейса?

1 Ответ

1 голос
/ 26 января 2010

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

Я понимаю идею управления состоянием , которая действительно важна с точки зрения клиента.

Что касается транзакций, это немного сложнее.

  • Тип транзакции (bean-managed или container-managed) - это детали реализации (я не уверен в вашем примере (a)).
  • Семантика распространения *1020* равна , а не . (required, mandatory, none и т. Д.).

Теперь - контейнер может захватить эти ситуации; но зачем ждать, пока во время выполнения?

Даже если бы все, что присутствовало с интерфейсом, системы типа все равно было бы недостаточно для обеспечения соблюдения правил при типе компиляции.

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

Почему семантика транзакции и требования полноты государства не являются частью интерфейса?

Интерфейс java содержит только ограниченный набор информации о правильном использовании компонента, будь то класс и бин или API. Общий контракт большинства компонентов намного сложнее, чем то, что представлено в интерфейсе.

Примеры:

  • Потоковая безопасность: как узнать, является ли определенный класс поточно-ориентированным, не заглядывая в документ?
  • ContentHandler.characters(): откуда вы знаете, что его можно вызывать более одного раза для каждого тега XML?
  • И этот список можно продолжить ...

Я лично использую термин контракт для обозначения полного набора ограничений. Интерфейс дает мне только сигнатуру методов с точки зрения системы типов.

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

Так что мой ответ будет: потому что, даже если бы это было так, вам все равно потребовалось бы больше информации.

...