Вопрос

Я большой поклонник сохранения логики приложения в сервлете и максимально упрощения JSP.Одна из причин этого заключается в том, что любой хороший веб-дизайнер должен иметь возможность расширить свои знания HTML, чтобы встроить несколько тегов JSTL для выполнения простых итераций, доступа к компонентам и т.д.Мы также сохраняем более сложные компоненты / ajax / js за библиотекой тегов (аналогично displayTag, но для наших собственных компонентов).

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

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

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

Я почти уверен, что прошу здесь невозможного и что мне придется от чего-то отказаться.Мой вопрос в том, что?

Редактировать

Ошибаюсь ли я, думая, что вся логика приложения должна быть полной до того , как звонить в JSP?У меня сложилось впечатление, что лучшей практикой считалось выполнять все запросы / вычисления / обработку в сервлете, а затем передавать (довольно) тупые компоненты в (очень) тупой JSP.

Существует пара методов, с помощью которых фактическая сложность запроса может быть инкапсулирована в другой класс (пользовательский тег или bean), и JSP может вызвать его.Это упрощает JSP (цель 1), но JSP все еще "запускает" запрос - довольно на поздней стадии процесса.

  • Неужели я все понял совершенно неправильно, и это нормально - делать это?
  • Является ли это общим правилом, но в данном случае это вполне нормально?
  • Могу ли я столкнуться с проблемами?

РЕДАКТИРОВАТЬ - Пример

Я надеюсь, что этот пример поможет:

Домашняя страница - это не "шаблон", подобный страницам категории / поиска - она специально разработана для того, чтобы очень хорошо работать, скажем, с маркетинговым изображением и парой изображений конкретного продукта.Однако в нем есть информация об этих двух продуктах, которые должны быть получены динамически (чтобы название и, что важно, цена) оставались синхронизированными с базой данных.

Сервлет не может знать, какие это будут продукты, потому что, если дизайнер захочет их изменить / удалить / добавить еще, ему нужно будет только отредактировать JSP (и, возможно, XML, как было предложено в одном из ответов).

Это было полезно?

Решение

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

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

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

ИЛИ ... вы разбиваете все на несколько запросов, используя XMLHttpRequest, и перезваниваете сервлету для каждого отдельного запроса, затем собираете страницу на клиенте.

Другие советы

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

Затем вы просто создаете метод, который будет искать продукт по идентификатору и возвращать этот компонент, чтобы дисплей мог извлекать нужные атрибуты.

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

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

Вы не ошибаетесь, думая, что вся логика приложения должна быть завершена перед рендерингом JSP.

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

В жизненном цикле одной страницы мне трудно понять, почему вы должны вызывать вызовы базы данных из JSP.Разве страница не была ранее размещена со всеми необходимыми переменными формы, чтобы помочь вам найти данные в классах Servlet / Helper?

Если бы вы могли привести пример какого-либо случая, это было бы полезно.

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

Я не уверен, в чем заключается вопрос.Если вы хотите иметь sql-инструкции из ваших jsp-страниц, то вы можете поместить их в файл свойств и просто прочитать файл свойств со страницы jsp.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top