Компоненты-сущности. Введение в компоненты-сущности. Крупные деловые объекты. Рост популярности компонентов-сущностей, страница 10

В обычном сценарии использования компонента-сущности присутствуют другие объекты Java как зависимые объекты данных. Например, компонент-сущность, представляющий банковский счет, может быть связан с несколькими объектами — адресами владельцев счета.

Поскольку зависимые объекты данных не могут существовать независимо от компонента-сущности, целесообразно моделировать такое отношение как агрегацию между классом реализации компонента-сущности и зависимым объектом данных. Пример этого отношения показан на рис. 13.16.

В еще одном возможном сценарии компонент-сущность взаимодействует с другими классами Java — объектами доступа к данным, о которых мы говорили выше. Такие отношения возникают, если для облегчения работы с персистентными полями логика доступа к данным выносится в отдельный класс. Моделирование отношений с такими объектами представлено на рис. 13.17.

Компоненты-сущности и компоненты JavaBeans

Одна из проблем, возникающих при использовании компонентов-сущностей — значительные затраты при каждом доступе к удаленному компоненту. Даже если к компоненту можно обращаться напрямую на той же машине, а не через сеть, эти затраты не исчезают, так как обращение к компоненту-сущности за данными обязательно проходит через контейнер. Как было сказано в предыдущей главе, помочь избежать таких удаленных вызовов и существенно повысить производительность на этом участке должно применение локальных клиентов, которые появились b J2EE 1.3.

Существует, однако, и другая причина возникновения затрат, которая не устраняется этим усовершенствованием — значительное количество действий по синхронизации, которые необходимы для сохранения целостности данных в экземпляре EJB. Рассмотрим, например, компонент-сущность, в котором хранится 20 разных фрагментов информации. При каждом обращении к любому из этих 20 фрагментов контейнер EJB должен гарантировать, что данные в объекте и в базе данных соответствуют друг другу, для чего обязательно надо вызвать метод еjbLoadили в jbStore.

Эту проблему можно решить тем же способом, который применяется в аналогичной ситуации для сеансовых компонентов — минимизировать количество обращений к компоненту-сущности, необходимое для выполнения определенной операции. В некоторых случаях это дает хорошие результаты; однако если в приложении есть много моментов, когда требуется получать данные от отдельных EJB, этим способом нельзя получить существенного выигрыша в производительности.

Объекты значения

Если программная система предприятия более сложна, для решения описанной выше проблемы можно попробовать применить другую более универсальную методику — инкапсулировать данные в компоненты JavaBeans и использовать их в схеме передачи по значению. В этом случае компоненты JavaBeans играют роль так называемых объектов значения (value object). Они сериализуются и распространяются по сети, после чего к ним можно по нескольку раз обращаться локально. Так как в этой схеме отсутствует синхронизация данных между объектом значения и компонентом-сущностью, имеет смысл делать компоненты JavaBeans неизменяемыми — только для операций получения данных, а не их изменения.

Эта методика имеет один существенный недостаток. По существу, она устраняет обычный процесс синхронизации данных, который автоматически выполняется в компоненте-сущности. Дело в том, что здесь мы обращаемся не к самому компоненту-сущности, а к другому объекту, который представляет данные этого экземпляра EJB в определенный момент времени. Нужно соблюдать осторожность, так как объект значения может выйти из синхронизации с настоящими данными в базе данных. Впрочем, во многих случаях этот подход работает хорошо.

В примере банковской системы HomeDirect мы используем эту методику, но продвигаемся еще на один шаг дальше. Вместо того, чтобы создавать компоненты JavaBeans для каждого экземпляра компонента-сущности, мы будем создавать JavaBeans при каждом действии, инициированном пользователем. Благодаря этому в JavaBeans каждый раз будут данные, соответствующие моменту, когда пользователь начинает какое либо действие на Web-сайте. Любую информацию, сохраняющуюся на более долгий срок, чем промежуток между действиями пользователя, мы будем считать потенциально устаревшей.