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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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