I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Struts vs. Zend Framework

03.29.2011
| 13551 views |
  • submit to reddit

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'); ?>

Conclusion

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.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mark Unknown replied on Tue, 2011/03/29 - 3:09pm

I had to check my calendar. Struts? I didn't know dicactical was another word for "stone age". You should only be jumping to Struts if you are doing support.

Giorgio Sironi replied on Wed, 2011/03/30 - 5:28am in response to: Mark Unknown

In a spin-off company of PoliMi, Struts is the target for code generation from higher-level models; they don't actually write Struts actions, but generate all of them for a portable deployment (requiring only a container).

Mark Unknown replied on Wed, 2011/03/30 - 9:15am in response to: Giorgio Sironi

Sadly, that says more about them and less about Struts. :(

Philopator Ptolemy replied on Thu, 2011/03/31 - 9:17am

Struts 2 is a lot closer to Spring MVC, in fact i find it pretty close to Grails.

It can be driven and configured by annotations, it has conventions plugin that hides most of common configuration and different actions can be grouped within the same class by using @Action.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.