Struts vs. Zend Framework

Я парень из PHP, который рискнул в мире Java благодаря университетским проектам. Struts используется в PoliMi в качестве наглядного примера инфраструктуры Java MVC для веб-приложений: это не современная мощная среда, подобная Spring MVC, но одна из самых консолидированных. Я также буду ссылаться на ветку 1.x Struts, поскольку она предшествует Zend Framework и может считаться одним из источников вдохновения для архитектуры PHP-фреймворков (наряду с Rails позже).

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

Давайте посмотрим, что вас удивит при переходе с Zend Framework на Struts или наоборот.

Немного истории

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

Zend Framework распространен и на производственных серверах PHP, в его версии 1.x. Symfony является самой популярной платформой PHP и была создана и одобрена Zend, компанией, которая имеет свои руки в самом интерпретаторе PHP (результаты опроса о популярности платформ будут опубликованы и прокомментированы на этой неделе).

Один сервлет против фронт-контроллера

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

Хотя можно утверждать, что Java-приложению не всегда требуется конструкция поверх Servlet Api, в PHP нет сервлетов и объектно-ориентированного интерфейса при запросе и ответе: Front Controller необходим как никогда . Это одна из тех частей, которые вы моментально пропускаете, если решите обходиться без рамок.

Классы действий против классов Action Controller

В веб-шаблоне MVC сгенерированные пользователем события представляют собой HTTP-запросы различных категорий, которые должны обрабатываться на стороне сервера. Struts поддерживает обработчик, определенный как классы с одним действием :

public class TestAction extends Action
{
  public ActionForward execute(
    ActionMapping mapping,
    ActionForm form,
    HttpServletRequest request,
    HttpServletResponse response) throws Exception{
      return mapping.findForward("testAction");
  }
}

Zend Framework предпочитает группировать действия в контроллерах действий , это другой тип класса контроллеров, который вызывается спереди:

class FooController extends Zend_Controller_Action
{
    public function barAction()
    {
        // do something
    }
}

Вопрос здесь в следующем: совместное использование методов и объектов между действиями (содержащимися в одном и том же классе в Zend Framework) является хорошим выбором? Конструкция Struts заставляет меня думать, что это на самом деле не нужно (действия могут также быть определены как подклассы общего базового класса, на всякий случай.)

Действительно, в Zend Framework действия могут быть более детальными. Тем не менее, группировка в контроллере удобна, поскольку помогает согласованию конфигурации : URL-адреса, такие как / controller-name / action-name , распознаются и автоматически маршрутизируются.

Постоянные случаи против ничего не поделились

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

Вместо этого контроллеры Zend Framework, как и все объекты PHP-пользователя, создаются с нуля для удовлетворения каждого запроса : я никогда не сталкивался с проблемой синхронизации, поскольку каждый экземпляр используется только один раз. Но я также видел, что это вызывает проблемы с производительностью , решением которых было определение некоторых новых оптимизированных конечных точек, которые полностью пропустили машину MVC.

Struts tag: <input:text name="fieldName" />
Zend Framework View Helper: <?=$this->formText('fieldName'); ?>