1

The web-app I'm currently building follows MVC. I've structured the servlets in a way such that they each handle related actions (so, one servlet may be responsible for all actions relating to setting up a user's account, while another may be used for user correspondance). Currently I have an "action" parameter attached to all query strings (for GETs), and request bodies (for POSTS), and use that in order to determine what action to take in these "related action" servlets.

In other words, my code is structured somewhat like this:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
{
    String action = request.getParameter("action");

    if(action.equals("login"))
    {
        .....
    }
    else if(action.equals("createAccount"))
    {
        ....
    }
    else if(action.equals("changePassword"))
    {
        ....
    }
    ..........
}

I'm relatively early in the development process, and as of now, I don't find any maintainability issues coming from this design. As per MVC, all the servlets do is call the methods of my utility classes; no actual work is done in them except for sending the responses back to the client. But by browsing SO, I'm coming across the sentiment that even moderately-sized (~10 or less "elses") if-else statements are code-smell and suggest the user isn't doing things the "OOP way".

Is there a better way to filter the types of requests coming in to my servlets? I'd like to be able to improve the maintainability of my app, but unwilling to implement OOP features just because they're OOP (similar to how people despise purists who insist on rigid encapsulation, to the point where they have 24 one-line getters/setters).

Kevin
  • 2,617
  • 29
  • 35
  • 2
    Duplicate of [Design Patterns web based applications](http://stackoverflow.com/questions/3541077/design-patterns-web-based-applications). To the point, you need a `Map` or just a MVC framework :) – BalusC Jun 02 '11 at 16:48
  • IMO more then 2 if/elses are a code smell. – Simeon Jun 02 '11 at 17:05
  • @BalusC: So I've taken a look at your linked answer and spent a couple of hours going over Spring's MVC implementation. Do you think it's a good idea to roll out my own Front-Controller implementation? Call it re-inventing the wheel, but I find the amount of work that it takes to setup a framework implementation of Front-Controller to be a bit ridiculous, especially when I see it involves creating Spring-specific XML files. That, and the added Spring dependencies make me apprehensive about adopting an entire framework just to refactor my current MVC implementation. I'm trying to avoid bloat – Kevin Jun 03 '11 at 02:54
  • That's why I like JSF 2.0 so much. No bloated XMLs. Just 2 extra JARs and one servlet entry in `web.xml` (or even nothing when using JSF 2.1 on Servlet 3.0). – BalusC Jun 03 '11 at 11:56

3 Answers3

2

Have you considered using a pre-baked MVC framework like Apache Struts, Spring, or Google SiteBricks? All of these are great, and might significantly reduce your code burden. I'd strongly recommend going that route. You'll save yourself some headaches and maintenance nightmares over rolling your own.

If you can't, for some reason, then honestly I don't think there's necessarily a problem with what you've done. It seems clear and maintainable. In effect, what you've done, is very similar to the way that micro-frameworks like Sinatra work for basic URL handling, albeit they do so with some nice syntactic sugar.

Jonathan
  • 7,536
  • 4
  • 30
  • 44
  • I've considered using Spring, but I just felt like it would add this conceptual overhead that I couldn't justify introducing... like I would be over-abstracting the web-app. In other words, I guess i wanted to remain as close to the code as possible so that I could remain mobile in the development process. – Kevin Jun 02 '11 at 16:59
  • Essentially all I need to do is to re-direct all requests to one servlet and create formal controller/action objects to handle the requests. I can fine-tune this as I like without having to work with a framework's rigid structure just to apply it to my app. Could you enlighten me on some of these "maintenance nightmares?" specific to rolling out my own implementation? Its a simple design pattern; as long as I stick to the structure that I set I can't see what Spring or any other framework would offer. – Kevin Jun 03 '11 at 03:02
  • The chief benefit of a framework is that it forces you to do things a certain way, and the good ones tend to enforce strict separation between model, view, and controller. Mixing them all up can lead to problems, but if you're comfortable with your own then there's really not much wrong with doing it that way. – Jonathan Jun 03 '11 at 11:38
2

Outside of using a framework as Jonathan suggested, you could also break functionality into multiple servlets. You would have to decide where the logical break is but your URLs would then resemble something closer to a REST API.

An example URL would be http://myapp.com/create_account or http://myapp.com/login

Each of the URLs could map to separate servlets.

Brad Gardner
  • 1,627
  • 14
  • 14
1

If you're just looking to avoid code-smell with the the large if statements and be a bit more OO, you can try using reflection-style instantiation if you can get your utility classes to implement the same interface. Basically, the value of the action parameter would be a representation of an actual classname (or a portion thereof, with appropriate values prepended or appended).

String action = request.getParameter("action");
Class clazz = Class.forName(action);
UtilityInterface utilityObj = (UtilityInterface)clazz.newInstance();
Asynkronos
  • 195
  • 5
  • This is the route I ended up going. I basically copied the functionality of Spring MVC, but used reflection based on the action parameters to determine which Action object (Controller in Spring) to use (as opposed to Spring which uses XML files to map controllers to urls). Very lightweight alternative to Spring – Kevin Jun 04 '11 at 04:54