Как правило, в реальных проектах на J2EE имеется совокупность разных типов компонентов-сущностей, которые связаны друг с другом и поэтому требуют применения этих отношений. Если вернуться к нашему примеру— компоненту, представляющему заказ клиента, очень вероятно, что подобный компонент-сущность будет представлять самого клиента. Такой компонент, скорее всего, будет иметь ссылки на совокупность своих заказов (любое число, включая нуль).
В языке UML эти отношения можно наглядно представить так, как показано на рис. 13.8.
Кратность
Этот рисунок изображает ситуацию, в которой клиент имеет ссылки на любое число заказов. Средствами UML это обозначено как кратность "*" у стрелки отношения около объекта заказа. Заметьте, что по умолчанию (если ничего не указано) принимается кратность 1. В предыдущем примере мы получили так называемое отношение "один ко множеству". Существует четыре возможных сочетания кратности:
· "один к одному";
· "один ко множеству";
· "множество к одному";
· "множество ко множеству".
"Один" в этих терминах означает, что метод доступа возвращает только один экземпляр компонента-сущности, на который он ссылается. Аналогично, "множество" означает, что метод возвращает "коллекцию" экземпляров данного компонента-сущности. Такая коллекция может иметь один из следующих четырех типов.
· Java.util.Collection
· Java.util.Set
· Java.util.List
· java.util.Map
Интересно, что для совместимости с J2EE 1.3 два последних типа не обязательно должны поддерживаться сервером приложений. Поэтому в зависимости от конкретного приложения они могут быть как доступны для использования, так и недоступны.
Необходимый код для передачи ссылок между компонентами-сущностями автоматически создается диспетчером персистентности. Это значительно упрощает разработку сложных систем, содержащих много компонентов-сущностей.
Направленность
Как можно заметить, на рис. 13.8 отношение изображается стрелкой, ведущей от клиента к заказу. Это означает, что отношение однонаправлено. Методы доступа к EJB клиента из EJB заказа не существуют, т.е. переход между компонентами возможен только в одном направлении. Такому отношению может соответствовать, например, ситуация, когда EJB клиента должен иметь возможность обращаться к своим заказам, но по соображениям безопасности недопустимо, чтобы конфиденциальная информация клиента была доступна непосредственно из экземпляра заказа.
Отношение, управляемое контейнером, может также быть двунаправленным и изображается двусторонней стрелкой. Это означает, что методы доступа будут созданы в обоих компонентах. Такому отношению соответствует ситуация, когда клиент может обращаться к коллекции сделанных заказов, а из любого данного заказа можно обращаться к информации клиента, который его сделал.
Дублирование управляемых контейнером отношений в J2EE 1.2
В версии J2EE 1.2 отношения, управляемые контейнером, также доступны для реализации и часто реализуются на практике. Отличие от J2EE 1.3 только в том, что методы доступа, возвращающие ссылки на экземпляры компонентов, должны быть написаны вручную. Диспетчера персистентности, который мог бы сделать это автоматически, bJ2EE 1.2 нет.
Локальные отношения
Следует заметить, что все описанные выше отношения подразумевают использование локального клиента, который был рассмотрен в конце главы 12. Чтобы можно было воспользоваться всеми преимуществами диспетчера персистентности, надо просто поместить все нужные компоненты-сущности в один файл архива, и они будут выполняться на одной и той же виртуальной машине Java.
Если же нельзя обойтись без использования удаленных клиентов, между ними также можно строить отношения, но код доступа для таких отношений придется писать вручную, как в J2EE 1.2.
Далее мы рассмотрим оставшиеся детали технологии компонентов-сущностей.
Технология компонентов-сущностей
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.