I am working on a small booking site right now. And that site has one single servlet with a big if-else block with around 85 conditions to redirect the request to the appropriate jsp. The same servlet contains some business logic. This servlet directly calls the data access objects. Those data access objects also have some business logic. So the business logic is shared between the servlet and the DAOs. I have two confusions.
1) The servlet is an anti-pattern. So I am trying to make it smaller and divide it into multiple servlets so that each servlet have some kind of specific purpose. My question is should I make one servlet for each conditions. That would make 85 different servlets.
2) How many layers should I have between the DAO and the servlets. I am thinking two because I need to one layer would convert the input specific to the web front end to a generalized request. And the second layer would process the generalized request and call the DAO’s when required. So that if later on when we decide to make a mobile app. We just need to make one layer of processing of request specific to the mobile front and and convert it to a generalized request. But this is leading to repeated code. I am a little confused between one layer and two layers.
I know its a big question to read. But thanks for your time and replies in advance.
If there are actions/conditions that are similar in purpose or in what they act upon, they can be combined into classes that have multiple handler methods. For example, all servlets that act on users could be combined into a single class. Whether or not that makes sense depends on information we don’t have.
How many layers should you have? Don’t know. In general there is at least one, a service layer. Services aggregate DAO functionality into transactional units. The condition handlers manage the interface between web and business layers.
It sure looks like you’re completely re-inventing a wheel which has been invented many times already. Consider either using an existing framework, or streamlining your existing code: instead of making multiple servlets to handle the conditions, dispatch to a command handler as de-coupled from the servlet spec as possible.
If you’re aiming for drop-dead simplicity, something like Bear’s Front Man is a thin, cute layer that does away with a lot of complexity and noise. Something like Guice Servlets allows dependency injection without a full-blown Spring/etc. stack.
Classes that handle a specific URL (or “command”–see any command pattern documentation) don’t need to be actual servlets; they can be generic classes.
They may be servlets–but the looser the coupling to the servlet specification you have, the easier things are to test and extend.
Getting from a URL to a “command” can be as simple as looking up a command in a map, instantiating the appropriate class, passing along various artifacts (e.g., request and session parameters), and calling a method in the implementation. In a sense, every framework ends up working like this on some level.