Controller Servlet

[Mark Hershberg]

When Using MVC design pattern where a controller servlet is the center of all the requests and responces, won't this make the servlet a big java class file with lots of if-else statements? or a huge switch-case block?

Is this quite normal for the controller servlet? or are there any workarounds for this?

Your help is appreciated.

[Frank Carver]

Not necessarily.

Sure. It can be done like that (and I have seen several books which seem to suggest such an approach) but it's a clumsy and not particularly scaleable way to tackle the problem.

The job of such a "controller servlet" is essentially to translate HTTP requests to method calls. This can be done using if or case but can also be done using plenty of other approaches.

One common approach is to use a Map to "regsister" objects to request names or URL fragments. The controller just extracts the important bit of the URL, looks up a handler object in the Map, and calls that object to do stuff. Typically no more than 10 lines of code or so.

Another popular approach is to use the "Chain of command" pattern where the controller simply hands off the request to a list of handlers, and each one gets to look at it and decide what to do with it (typically the options are handle it and end, handle it and continue with other handlers, and do nothing).

Another approach is to use reflection. The controller again extracts the important bit of the request URL, and then uses the reflection API to try and find a class or method that has the same name, and then call it. This approach can allow applications to be changed and configured without recompilation.

I'm sure there are many more approaches to this common problem.

[Ilja Preuss]

As Frank says.

I'd also like to add that MVC doesn't really *require* that there is one central servlet. It just requires that you have a Controller layer that is decoupled from the Model and View layers. The Controller layer could well be composed of any number of servlets.