Один из этих механизмов — персистентность с управлением от контейнера. В большинстве компонентов-сущностей этот режим работы должен использоваться как можно чаще. Если персистентностью будет управлять контейнер EJB, все операции доступа к базе данных и синхронизации будут производиться автоматически. Так как для этого используются заранее встроенные и проверенные функции контейнера, мы сразу получаем высококачественную поддержку персистентности, не требующую реализации и проверки кода.
Другой механизм — персистентность с управлением от компонента. В этом режиме также используется компонент-сущность, но требуется дополнительно написать код функций доступа к данным и синхронизации. Для этого подхода рекомендуется использовать отдельный объект, обычно называемый объектом доступа к данным. Методы в таком объекте привязываются к методам еjbLoad и еbStore, которые имеются в реализации компонента-сущности. Таким образом упрощается возможный переход в будущем к персистентности с управлением от контейнера, так как для этого надо будет просто удалить сосредоточенный объект доступа к данным, а не выискивать и удалять код, рассеянный по всему компоненту-сущности.
Если управление от контейнера дает солидные преимущества, зачем вообще нужна перси-стентность с управлением от компонента? Наиболее обычная причина ее использования — та, о которой мы упомянули выше, а именно облегчение перехода от компонентов, в которых нужно только написать код доступа к данным, к полнофункциональным компонентам-сущностям.
Следует также отметить, что компоненты-сущности — не единственное средство обеспечения персистентности. Если в приложении нужно только простое обращение к данным, которые не будут меняться часто, и не возникают проблемы распараллеливания доступа, вероятно, лучше всего будет просто написать собственный объект доступа к данным. Все механизмы, описанные выше, схематически показаны на рис. 13.5.
Используются возможности компонента-сущности в полном объеме
Транзакции и параллельная обработка
Во всех компонентах-сущностях используется демаркация транзакций с управлением от контейнера, которая обеспечивает правильное выполнение параллельной обработки. Это означает, что любой данный экземпляр компонента-сущности одновременно доступен для любого количества клиентов, если только клиенты знают, как найти этот экземпляр, и имеют необходимые права доступа.
Как и в сеансовых компонентах, для методов, вызываемых клиентом, могут быть установлены атрибуты транзакции. К таким методам относятся все определяемые пользователем методы местного и удаленного интерфейсов. Значения атрибутов точно такие же, что используются в сеансовых компонентах.
Абстрактная персистентность
В J2EE 1.3 появился очень привлекательный новый способ управления персистентностью для компонентов-сущностей. Он применяется только в случае персистентности, управляемой контейнером. Суть этого способа заключается в полном отделении реализации компонента от его представления. Такое разделение приводит к появлению двух новых концепций, которые мы еще не рассматривали: схемы абстрактной персистентности и диспетчера персистентности.
Схема абстрактной персистентности
Одна из проблем с кодом доступа к данным, которая часто возникала перед разработчиками, состояла в том, что конкретные детали базы данных, для которой создавался этот код, становились полностью известны лишь на очень поздней стадии процесса разработки. Причиной было то, что проектирование базы данных и проектирование EJB часто выполнялись двумя разными группами. Могло также быть, что структура база данных в новой версии полностью обновлялась, и разработчики хотели избежать переделки всех ранее созданных для этой базы данных компонентов EJB.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.