Предложения по шаблону проектирования JSP/Servlet для веб-приложения

Я работаю в RESTful Web Framework, основанном на собственном скрипте (JSP). В Framework есть механизм маршрутизации, который автоматически устанавливает ряд атрибутов запроса, которые затем становятся доступными в JSP (один из атрибутов является «моделью» запрошенного ресурса, который в основном представляет собой просто HashMap).

Проблема заключается в том, что в 90% случаев в JSP требуется добавить некоторую логику, будь то более сложная логика предметной области, извлечение данных других ресурсов (других моделей) или очистка данных для вывода.

Я рассматриваю различные шаблоны проектирования веб-приложений для извлечения логики домена из JSP и сохранения JSP как можно менее логическим.

Несколько замечаний:

  1. В системе, в которой я работаю, предоставляется модель (извлечение данных из базы данных), но фреймворк (ранее упомянутый HashMap); Я мог бы создать свои собственные оболочки модели вокруг этих данных, но это, вероятно, не нужно.
  2. JSP/скрипты являются конечными точками для запросов. Если я использую шаблон, который использует объект типа Presenter/Controller, который возвращает компонент представления (ViewModel?), который содержит все данные, которые будет использовать представление, мне потребуется строка в JSP, который вызывает Presenter/Controller и создает экземпляр bean-компонента View.

В настоящее время я создал POJO Presenter для каждого модуля (скрипта), который имеет доступ к модели (опять же, Framework устанавливает это как атрибут запроса), и просто создаю его экземпляр в верхней части JSP и использую его больше или меньше похож на фасоль.

Если я правильно понимаю, я считаю, что реализовал шаблон проектирования Presentation Model. [1]

Ex.

JSP выглядит так:

<% DemoPresenter demo = new DemoPresenter(request) %>
<%= demo.getTitle() %>
- or add it to pageContext to use w JSTL/EL -
<c:set var="demo" value="new DemoPresenter(request)"/>
${demo.title} 

А «Ведущий/Контроллер» выглядит так:

public class DemoPresenter extends BasePresenter { 

   private String title; 

   public DemoPresenter(HttpServletRequest request) { 
       FrameworkModel model = request.getAttribute("frameworkProvidedResourceModel");
       this.title = model.get("title").toUpperCase() + "!!!";
   } 

   public getTitle() { return this.title; } 
}

Любые мысли об использовании объекта Presenter непосредственно в JSP/Script, по сравнению с тем, чтобы он возвращал «без логики» bean-компонент ViewModel, который Presenter заполняет данными? Преимущество этого заключается в том, что один докладчик может управлять различными «представлениями» одного и того же ресурса (такими как представление «Показать», «Редактировать», «Сводное представление» и т. д.). Ниже приведен пример того, как я могу получить различные представления. модели.

/blog/posts/1/show -> выполняет JSP, который получает ViewModel следующим образом:

<% DemoDefaultViewModel default = new DemoPresenter(request).getViewModel(DemoDefaultViewModel.class); %>

/blog/posts/1/edit ->выполняет JSP, который получает ViewModel следующим образом:

<% DemoEditViewModel edit = new DemoPresenter(request).getViewModel(DemoEditViewModel.class); %>

Я хотел бы сохранить простое решение без слишком большого количества посторонних деталей. Я также не могу слишком увлекаться, поскольку я работаю в строгой предопределенной структуре - я просто хочу найти хороший способ перенести всю логику моей предметной области из JSP в более пригодные для повторного использования, тестируемые классы Java.

[1] http://martinfowler.com/eaaDev/PresentationModel.html


person empire29    schedule 08.07.2012    source источник


Ответы (2)


Проверьте struts.
Должен признаться, что использовал только старую версию, но идея сервлета с «фронт-контроллером», похоже, именно то, что вам нужно. Это специальный сервлет для запуска общего кода и маршрутизации запросов.
У него также есть действия, которые можно протестировать вне веб-контейнера.

День, когда я перешел с чистого JSP на struts, был одним из лучших дней в моей жизни веб-разработки! Проект стал более организованным, и им стало намного легче управлять.

person davidfrancis    schedule 08.07.2012
comment
День, когда я перешел с чистого JSP на Struts, был одним из лучших дней в моей жизни веб-разработки! - Я уважаю твой опыт, чувак! Бьюсь об заклад, вы сделали это более десяти лет назад. В противном случае переезд в Struts был бы переходом в каменный век. В 2012 вам точно стоит уйти от JSP, но не к Struts, а к HybridJava! - person Dima; 12.07.2012

Существует множество фреймворков MVC. Например, Struts использует сервлет переднего контроллера для отправки запросов классу (контроллеру) в зависимости от используемого ресурса. Класс обрабатывает запрос и отправляет результат в представление (обычно JSP). Модель — это любой класс, представляющий ваши данные. К вашему сведению, карта не является фреймворком. Представление ваших данных только в виде MAP будет работать, но это уродливо и сложно в обслуживании.

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

person Romski    schedule 08.07.2012
comment
К сожалению, я привязан к этой структуре, хорошо это или плохо. Я также знаю, что карта — это не фреймворк, я просто отмечал, как фреймворк изначально предоставляет данные для просмотра. - person empire29; 08.07.2012
comment
Какие рамки это? Не повезло, если это домашний! Где вмешивается фреймворк? Судя по вашему описанию, это как минимум уровень данных. Если это только там, то вы можете посмотреть на использование структуры внешнего интерфейса, такой как struts, jsf, wicket или любой из многих. Лично я хотел бы как можно быстрее превратить свои карты в объекты предметной области. Как с точки зрения разработки, так и с точки зрения кода. Имея в виду, что экземпляр карты доступен в коде, превратите его во что-то значимое. - person Romski; 09.07.2012