Over a million developers have joined DZone.
Platinum Partner

Struts vs. Zend Framework

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

I am a PHP guy that has ventured in the Java world due to university projects. Struts is used at PoliMi as a dicactical example of Java MVC framework for web applications: it is not a modern all-powerful framework like Spring MVC, but it is one of the most consolidated ones. I will also refer to the 1.x branch of Struts as it is the one who predates Zend Framework, and can be considered one of the inspirations for PHP frameworks architecture (along with Rails later).

This article is intended to be useful for who experiences a transition between Java and PHP, but also to learn what could be imported in a framework from the other. Keep in mind that in the PHP world using a framework is probably still not considered the default option (going with or without frameworks is a choice which is out of the scope of what I want to discuss today instead.)

Let's see what surprises you when jumping from Zend Framework to Struts, or the other way around.

A bit of history

Struts 1.x was adopted by the Apache foundation in 2000, and today is a battle-tested technology that can be used both for didactical purposes or as a production platform, or even as a target for code generation (so I heard).

Zend Framework is diffused in production PHP servers as well, in its 1.x version. With Symfony is the most popular PHP frameworks and it was created and endorsed by Zend, a company that has its hands in the PHP interpreter itself (the results of the poll on frameworks popularity will be published and commented this week.)

Single Servlet vs. Front Controller

Struts provides a single entry point which the servlet container should be configured for. This entry point is a single servlet, which deals with routing and choosing the right action to perform and view to render.

While one can argue that Java application do not always need a construct over the Servlet Api, in PHP there are no servlets and no object-oriented interface upon the request and response: a Front Controller is more necessary than ever. It's one of the single parts you instantly miss if you decide to go without frameworks.

Action classes vs. Action Controller classes

In the web-based MVC pattern, the user-generated events are HTTP requests of various categories, which must be handled by the server-side. Struts supports handler defined as single action classes:

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

Zend Framework prefers to group actions in action controllers, a different kind of controller class, which is called from the front one:

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

The question here is: sharing methods and objects between actions (contained in the same class in Zend Framework) is a good choice? Struts design makes me think that is not really necessary (actions could also be defined as subclasses of a common base class, just in case.)

Indeed actions could be more granular in Zend Framework. However, the grouping in controller is handy as it aids convention over configuration: urls such as /controller-name/action-name are recognized and automatically routed.

Persistent instances vs. shared nothing

Servlet before, and then Actions, have a lifecycle controlled by the platform: multithreaded and thus spanned over multiple requests.

Zend Framework's controllers instead, like all PHP userland objects, are created from scratch to satisfy each request: I've never encountered a problem with synchronization as each instance is used only once. But I've also seen this causing performance problems whose solution was defining some new optimized endpoints that skipped the MVC machine altogether.

Configuration vs. convention

I think (heresy) that Zend Framework is definitely more influenced by RoR than first-generation Java frameworks, even if we do not admit it. When you add methods to a controller, there is no XML configuration to be added: they are automatically exposed with a default Url, like in Rails.

Note that in Zend Framework convention is just one way of doing things, and it's always overridable. For example you can define custom urls, mapped with regular expressions routes, that targets already existing actions.

JSP vs. embedded PHP

The presentation layers of Java and PHP applications are very similar: they print by default HTML code, in which dynamic parts (even real code) can be embedded.

Even in the PHP world, there is no consensus about an additional language for defining views: PHP was originally a templating language by itself.

Neither JSP nor PHP templates automatically force the user to not include business logic in views: but then, who does?

Tag libraries vs. View Helpers

Trying to take away logic and actual code from the view, the View Helpers are implemented in both platforms. If you are learning one of the two, save yourself the from-scratch explanation of why they are necessary: Zend Framework's View Helpers are a PHP-based implementation of tag libraries, and tag libraries are an XML implementation of View Helpers.

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


This article is getting long, but I'm glad I have dived into a new platform for web programming, even in the reduced version of Struts. Even when you do not get to use a new tool in production, it still feels good to learn what assumptions about web development are coming from your framework and not from HTTP and its technologies.

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}