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

Этот подход позволяет избежать проблем, связанных с потерей синхронизации, и сосредоточить большую часть работы над кодом представления на самом компоненте JavaBeans. Можно сказать, что JavaBeans будет местом для "складирования" и обработки данных, которые мы собираемся отобразить. Он будет обращаться к каждому экземпляру компонента-сущности, который мы захотим запросить, и забирать из него нужные данные в одном деловом методе. Когда JavaBeans соберет и обработает всю информацию из экземпляра EJB, он возвратит полученные результаты на страницу JSP.

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

Пример использования объекта значения показан на рис. 13.18.

Можно также применять еще одну разновидность объекта значения — объект деталей (details object). В этой методике весь компонент-сущность упаковывается в объект Java и используется для обращения к данным. Возможно и изменение данных клиентом; для этого пользователь должен обновлять компонент-сущность локально, а затем по этой локальной копии производится обновление настоящего компонента-сущности. Можно даже обеспечить доступ к объекту деталей на уровне класса компонента. Однако этот подход влечет за собой некоторые трудности, подобные тем, что возникают при использовании объекта значения.

Компоненты-сущности, сервлеты и JSP

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

Описанные отношения моделируются как ассоциации. Пример ассоциации между сервлетом и компонентом-сущностью показан на рис. 13.19.

Хотя для той же цели можно использовать компоненты JSP (в конце концов, они компилируются в сервлеты), все же предпочтительнее, чтобы JSP применялись для представления данных, а доступ из них к компонентам-сущностям, когда это требуется, производился через промежуточный сервлет. Этот подход дает более четкое разделение между представлением и логикой приложения. Кроме того, если сервлет и компонент-сущность связываются напрямую, а не через сеансовый компонент, это положительно влияет на производительность, так как сервлеты потребляют меньше системных ресурсов. Пример доступа через сервлет показан на рис. 13.20.

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

Хотя в J2EE нет ограничений на доступ к компонентам-сущностям непосредственно из сервлета или JSP, в большинстве случаев более целесообразно обращаться к ним через сеансовые компоненты, на которые можно возложить все обязанности по управлению ходом событий в приложении. Отношения между сеансовыми компонентами и компонентами-сущностями легко изображаются в UML как зависимости или однонаправленные ассоциации от сеансового компонента сеанса к компоненту-сущности. Если сеансовый компонент не сохраняет информацию о компоненте-сущности от одного вызова метода до следующего, такое отношение можно смоделировать как зависимость. Если же сведения о компоненте-сущности должны сохраняться длительное время, отношение моделируется как ассоциация.

Пример связи сеансового компонента и компонентов-сущностей показан на рис. 13.21.

Чаще всего применяется подход1, в котором сеансовые компоненты играют роль "фасадов" компонентов-сущностей. Такой подход позволяет упростить клиентский интерфейс, поскольку клиенту предлагается единственная точка входа для каждой операции, возможно, охватывающей несколько компонентов-сущностей. Аналогично, пользователь, размещающий заказ на Web-сайте, и администратор, производящий инвентаризацию товаров, могут работать с одними и теми же данными через разные сеансовые компоненты, соответствующие разным операциям.