The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Web мастеру, CGI, Perl, PHP, Apache" / Оглавление документа


Quick Links

2. Разработка Model-компонентов

Home

2.1 Обзор

Table of Contents

Обычно много внимания при разработке web-приложений уделяется View. Однако, вы должны гарантировать, что обработка каждого посланного пользователем запроса также ясно определена с точки зрения Model. Обычно разработчик Model-компонентов сосредотачивается на создании JavaBean-классов, которые поддерживают функциональные требования. Точные характеристики beans, требуемых конкретным приложением могут сильно меняться в зависимости от этих требований, они они в общем могут быть классифицированы и подразделены на несколько категорий, обсуждаемых ниже в этом разделе. Однако первым делом мы рассмотрим краткую концепцию термина “scope” (англ. область) и его связь с beans.

Introduction

Model Components

View Components

Controller Components

Resources

Who We Are

2.2 JavaBeans и Scope

Внутри web-приложений объекты JavaBeans могут сохраняться в (и извлекаться из) наборе различных коллекций “атрибутов”. Каждая коллекция имеет различные правила, регламентирующие время жизни коллекции и видимость объектов-beans, помещенных в нее. В совокупности, правила времени жизни и видимости beans называется scope (областью видимости) beans. Спецификация JavaServer Pages (JSP) определяет различные варианты scope, используя следующие термины (эквивалентные концепции из Servlet API приведены в круглых скобках):
  • page – beans которые видимы в пределах единственной JSP-страницы, в течение времени жизни текущего запроса (это локальные переменные метода service())
  • request - beans, которые видны на единственной JSP странице, а также любой странице и сервлете, который включен в эту страницу, или перенаправлен с этой странице (атрибуты запроса (Request attributes))
  • session – beans, которые всем JSP страницам и сервлетам, которые участвуют в конкретной сессии пользователя, в одном и более запросах (атрибуты сессии)
  • application – beans, которые видимы всем JSP-страницам и сервлетам, являющимся частью web-приложения (Servlet context attributes)
Важно помнить о том, что сервлеты и JSP-страницы в одном web-приложении совместно используют тот же самый набор коллекций beans. Например, bean, сохраненный в атрибуте запроса (request attribute) в сервлете примерно так:
MyCart mycart = new MyCart(...);
request.setAttribute("cart", mycart);
немедленно становится видимым на JSP-странице, на которую Сервлет передал управление, используя стандартный тэг:
<jsp:useBean id="cart" scope="request"
class="com.mycompany.MyApp.MyCart"/>

2.3 ActionForm Beans

Примечание: ActionForm beans на самом деле ближе к View, чем к Model.
При использовании Struts обычно предполагается, что необходимо определить ActionForm bean (то есть, Java-класс, расширяющий класс ActionForm) для каждой формы ввода, требуемой для вашего приложения. ActionForm beans иногда называют просто “form beans” (beans для формы). Если вы определяете такие beans в конфигурационном файле ActionMapping (см. " Разработка компонентов Controller"), то сервлет-контроллер Struts автоматически выполнит для вас следующие действия, прежде чем вызвать соответствующий Action:
  • Проверяет, нет ли в пользовательской сессии экземпляра bean соответствующего класса, с соответствующим ключом.
  • Если в сессии нет такого Bean, то создается новый экземпляр и автоматически добавляется к пользовательской сессии (ес-но, со scope = session)
  • Для каждого параметра запроса чье имя соответствует имени свойства в bean, вызывается соответствующий setter-метод (т.е. setXXX, см. спецификацию JavaBeans). Это действует примерно так же, как стандартное действие для JSP <jsp:setProperty>, когда вы используете wildcard “*” для того, чтобы выбрать все параметры.
  • Обновленное ActionForm bean передается в метод perform() класса Action во время его вызова, обеспечивая немедленный доступ к его значениям
Когда вы будете программировать ваши ActionForm beans, старайтесь соблюдать следующие принципы:
  • Сам по себе ActionForm класс не требует реализации никаких специфических методов. Он используется для определения роли, которую данное конкретное bean играет во всеобщей архитектуре. Обычно ActionForm bean имеет только getter и setter методы для своих свойств - и никакой бизнес-логики.
  • Объект ActionForm также предлагает стандартный механизм проверки (standard validation mechanism). Если вы переопределите заглушку для метода и обеспечите сообщения об ошибках в стандартном ресурсе приложения, то Struts автоматически проверит данные, вводимые в форме (используя ваш метод). Подробнее смотрите "Автоматическая проверка Form". Конечно, вы также можете проигнорировать проверку в ActionForm и обеспечить свою собственную в объекте Action.
  • Определяйте свойство (с соответствующими методами setXxx() и getXxx()) для каждого поля в html-форме. Имена полей и свойств должны соответствовать друг другу согласно обычным соглашениям JavaBean. Например, для поля с именем username будет вызван метод setUsername().
  • Представляйте ваши ActionForm beans как стену (firewall) между HTTP и Action. Используйте проверку для того, чтобы гарантировать наличие всех требуемых свойств и то, что они содержат разумные значения. ActionForm, которая не прошла проверку, не будет даже передана в Action для обработки.
  • Вы можете расположить экземпляр bean на вашей форме и использовать вложенные ссылки на свойства. Например, вы можете иметь bean “customer” в вашем ActionForm, и затем обращаться к свойству "customer.name" на JSP. Это будет соответствовать вызову методов customer.getName() и customer.setName(string Name) в вашем customer bean. Подробнее о синтаксисе вложенных свойств смотрите Tag Library Developer Guides (Руководства по использованию библиотек тэгов).
  • Предупреждение: Если вы вкладываете существующий экземпляр bean в вашу форму (имеется в виду ActionForm, конечно), то подумайте о свойствах, которые bean предоставляет. Любое public-значение в ActionForm, которое принимает String-значение, может быть установлено с помощью строки запроса (query string). Может быть полезно помещать подобные beans в “тонкую обертку”, которая будет предоставлять (открывать) только необходимые в данном случае свойства. Также эта обертка может обеспечивать фильтр, для того чтобы быть уверенным в том, что свойства во время выполнения не установлены в неподходящие значения. (Прим. перев.: данное предупреждение относится прежде всего к вопросам безопасности – необходимо помнить о том, что HTTP request может быть сформирован не только в вашей JSP, а также другими средствами – с целью хищения информации, например, и поэтому надо всегда проверять входные данные на адекватность)
Вы должны заметить, что “form” (форма) в том смысле, как это обсуждается здесь, не обязательно соответствует единственной JSP-странице в пользовательском интерфейсе. Обычное дело во многих приложениях – это иметь “form” (c точки зрения пользователя), которая “растянута” по многим страницам. Подумайте, например, о стиле пользовательского интерфейса в виде мастеров (wizard style user interface), который обычно используется во время установки нового программного обеспечения. Struts дает возможность определить единственную ActionForm bean, которое содержит свойства для всех полей, вне зависимости от того, на какой странице они в действительности будут отображены. Аналогично, различные страницы для одной и той же формы должны быть переданы на обработку (submitted) к одному и тому классу Action.
Если вы следуете этим предложениям, то дизайнеры могут изменять порядок расположения полей на и между различными страницами, и часто без изменения логики обработки.

2.4 System State Beans (Beans состояния системы)

Реальное состояние системы обычно представлено как набор из нескольких JavaBeans классов, чьи свойства определяют текущее состояние. Система корзины покупателя, например, будет включать bean для представления корзины, который будет храниться для каждого отдельного покупателя и будет (помимо других вещей) включать набор тех продуктов, которые покупатель в данный момент отобрал для покупки. Отдельно, система будет включать различные beans для хранения информации о профиле пользователя (включая его кредитную карту и ShipTo адрес), так же как и каталог доступных продуктов и их текущие количества на складе.
В небольших системах, или когда информацию о состоянии не нужно хранить длительное время, набор beans состояния системы может содержать все знания, которые система когда-либо имеет. Или, как это часто случается, beans состояния системы представляют информацию, которая постоянно хранится в некой внешней базе данных (например, объект CustomerBean который соответствует конкретной строчке в таблице CUSTOMERS), и создаются и уничтожаются из хранилища на сервере когда это необходимо. В очень больших приложениях для этих целей используются Entity Enterprise JavaBeans.

2.5 Business Logic Beans (Beans бизнес-логики)

Вы должны инкапсулировать функциональную логику вашего приложения в виде вызовов методов классов JavaBeans, спроектированных для этой цели. Эти методы могут быть частью тех же классов, которые используются для Beans состояния системы, или же они могут быть в отдельных классах, выделенных для выполнения логики. В последнем случае, как правило, вам необходимо будет передавать beans состояния системы в качестве параметров.
Чтобы обеспечить максимальное повторное использование кода, beans бизнес-логики должны быть спроектированы и реализованы так, чтобы они ничего не знали о том, что они запускаются в среде web-приложения. Если вы импортируете классы из javax.servlet.* в ваш bean, то вы привязываете эту бизнес логику к среде выполнения web-приложений. Рассмотрите вопросы перестройки (rearranging things), которые выполняют ваши Action классы (часть роли Контроллера, как описано ниже): переводят всю необходимую информацию из HTTP-запроса в вызовы getter и setter-методов свойств ваших beans бизнес-логики, после чего можно вызвать метод execute(). Подобные бизнес-классы могут быть повторно использованы не только в web-приложениях, для которых они первоначально создавались.
В зависимости от сложности и масштаба вашего приложения, beans бизнес-логики могут быть обычными JavaBeans, которые взаимодействуют с beans состояния системы, передаваемые как в качестве параметров, или обычными JavaBeans, которые обращаются к базе данных используя вызовы JDBC. Для крупных приложений, вместо этих beans часто используются stateful или stateless (с сохранением состояния или без сохранения состояния)Enterprise JavaBeans (EJBs).

2.6 Доступ к реляционным базам данных

Struts могут определять datasources (источники данных) для приложения в своем стандартном конфигурационном файле. Также предусмотрен простой пул JDBC-соединений. Подробнее смотрите Конфигурационный файл Action Mappings, и Utilities Developer Guide.
После определения datasource, можно воспользоваться примером установления соединения внутри метода perform() класса Action.
public ActionForward
       perform(ActionMapping mapping,
               ActionForm form,
               HttpServletRequest request,
               HttpServletResponse response)
{
 try {
   javax.sql.DataSource dataSource =
     servlet.findDataSource(null);
   java.sql.Connection myConnection =
     dataSource.getConnection();

   //делайте что вам нужно с экземпляром myConnection
 } catch (SQLException sqle) {
   getServlet().log("Connection.process", sqle);
 } finally {

   //завершает все это блок finally, который
   //гарантирует, что connection закрыт
   try {
     myConnection.close();
   } catch (SQLException e) {
     getServlet().log("Connection.close", e);
   }
 }
}
Обратите внимание, что общий пул соединений Struts являет опциональным компонентом. Множество приложений на базе Struts использует другие пулы соединений для получения наилучшей производительности, особенно на промышленных системах большого объема.
Далее: Разработка View-компонентов

Copyright (c) 2000-2002, Apache Software Foundation






Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру