JSP vs Velocity, что лучше?

Что лучше между JSP и скоростью в - Представление - Простота использования - Простота создания многоразовых компонентов - Наличие сторонних разработчиков с открытым исходным кодом - Поддержка IDE

Ответ 1

Преимущества скорости:

  • строгое разделение представления от бизнес-логики
  • простой синтаксис, который может быть понят графическими дизайнерами

Ответ 2

@Vartec: Я не думаю, что "строгое разделение взгляда от бизнес-логики" - это функция скорости, которой нет в jsp. Вы можете сделать бизнес-логику в jsp (более или менее), но это не рекомендуется вообще. Но я согласен с вами в отношении синтаксиса.

Производительность

JSP скомпилирован на Java, поэтому я не думаю, что скорость быстрее. (сами не делали тестов)

Простота использования

Для дизайнеров: скорость Для программистов: (IMHO) jsp, потому что он ближе к коду

Простота создания компонентов многократного использования

JSP имеет множество компонентов Velocity не имеет компонентов (не ориентированных на компоненты)

Доступность сторонних разработчиков с открытым исходным кодом

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

Поддержка IDE

Существует множество инструментов для jsp. Особенно в плагине/наборе инструментов eclipse jboss есть хороший редактор jsp.

Плагины для Velocity в основном не являются функциональными или довольно базовыми (вам повезло, если у вас есть подсветка синтаксиса)

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

Ответ 3

Ниже приведено описание Freemarker, но сравнения, вероятно, все еще актуальны.

На этом этапе развития этих двух технологий кажется, что основными причинами выбора одного из них являются:

  • Есть что-то конкретное, что вам нужно, это одно, а не другое.
  • Вы хотите, чтобы разработчики не помещали Java-скрипты в страницы JSP.
  • Ваши разработчики более удобны в одном, чем другие

Причины, по-видимому, не оказывают такого воздействия:

  • Скорость. В типичном приложении Java EE существует так много уровней, которые оказывают гораздо большее влияние, чем несколько миллисекунд, более или менее, что может сделать рендеринг представления. На самом деле, это, вероятно, последний уровень, который я бы рассмотрел, если мое приложение выполняло подпункт.
  • Поддержка IDE. JBoss Tools предоставляет редактор Freemarker, а инструменты JSP хорошо известны.
  • Синтаксис. JSP 2 и Freemarker имеют практически идентичный синтаксис для многих базовых операций из-за EL и JSTL.

Пример Freemarker:

<#list foos as foo>
  <tr>
     <td>${foo.field1}</td>
     <td>${foo.field2}</td>
     <td>
        <#list foo.childObjects as child>
           <#if child.name == 'bar'>
              ${child.value}
           </#if>
        </#list>
     </td>
  </tr>
</#list>

JSP-EL-JSTL Пример:

<c:forEach items="${foos}" var="foo">
  <tr>
     <td>${foo.field1}</td>
     <td>${foo.field2}</td>
     <td>
        <c:forEach items="${foo.childObjects}" var="child">
           <c:if test="${child.name == 'bar'}">
              ${child.value}
           </c:if>
        </c:if>
     </td>
  </tr>
</c:forEach>

Ответ 4

Скорость или даже лучше FreeMarker. В JSP у вас не может быть диспетчеризация времени выполнения для иерархии pojo, и все статически типизировано, что является болью. Более того, если вы создадите много настраиваемых тегов JSP2.0 (скажем, более 100-150), ваш цикл развертывания развертывания значительно замедлит работу из-за неэффективности Jasper для эффективного решения зависимостей.

С другой стороны, JSP имеет отличную поддержку инструмента.

медленные ссылки на компиляцию JSP:

http://www.mailinglistarchive.com/[email protected]/msg10786.html

http://marc.info/?l=tomcat-dev&m=119377083422720&w=2

Ответ 5

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

Это зависит от того, что вы действительно хотите сделать. Сервлеты в сочетании с Velocity (или FreeMarker, если на то пошло) предлагают очень хорошее разделение логики и презентации. Шаблоны сложнее протестировать, потому что вам нужно будет оценить шаблон, чтобы иметь возможность судить о том, что HTML (или что бы то ни было, это формат вывода). Для JSP это можно сделать в вашей IDE по выбору.

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

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

Ответ 6

Преимущества скорости в соответствии с вышеизложенным пропущают пару очень важных вещей с точки зрения инженеров:

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

Те последние два действительно делают Velocity полезными по сравнению с JSP.

Ответ 7

Я не знаю, сможет ли Velocity конкурировать с JSP во всех аспектах, но скорость быстрее и нуле. Эффективность Velocity на 35-45% больше, если это сложные веб-страницы, которые могут быть уменьшены, но все же это На 5% больше, чем JSP.

Ответ 8

Скорость лучше   Он адаптируется ко многим областям применения   Он предлагает простой, понятный синтаксис для дизайнера шаблонов   Он предлагает простую модель программирования для разработчика   Поскольку шаблоны и код являются отдельными, вы можете разрабатывать и поддерживать их самостоятельно   Двигатель Velocity легко интегрируется в любую прикладную среду Java, особенно сервлеты   Velocity позволяет шаблонам обращаться к любому общедоступному методу объектов данных в контексте