0

I'm coding my first servlet (academic purpose) and I not have clear what is the proper way to do the interface with HTML client.

If the client requests are of many type, like "I want a coffee", "I want a pizza" etc, (actually I think I'll need only login and data send/request) however, how the servlet must handle these? considering that a servlet have only one get/post method.

A) one servlet (serverAddr/myApp/myServlet) that check with a parameter which request is received and call the proper function (with a switch. Don't sound good).

B) a servlet with specific purpose for each request, like "doCoffee" (serverAddr/myApp/coffee), "doPizza" (serverAddr/myApp/pizza) etc. In this case, I have many servlet that form the web application.

I hope have explained my question, thanks.

newUser.java
  • 197
  • 1
  • 3
  • 12
  • It depends. If it's actually about coffee and pizza then A would make more sense. – Jimmy T. Aug 20 '16 at 22:38
  • What matters is not the number of servlets. What matters is to have a clean HTTP API (and thus clean URLs), and to have clean, maintainable code, where two unrelated use-cases are not implemented in the same class. If you just use servlets, two servlets are probably better. If you design, or use, an action-based framework such as Spring MVC, then a single servlet dispatching to action classes based on the URL offers many advantages. – JB Nizet Aug 20 '16 at 22:43
  • thank you, very helpful. – newUser.java Aug 21 '16 at 09:39

1 Answers1

0

You are right : the two solutions (a doGet() methods which handles multiple use cases and as many servlets as usecases) are not good design in a general way.

That's why, since very long time, Java EE applications don't use massively directly their own HttpServlet implementation but use Java EE UI frameworks which allow to have a flexible design in the web controllers.
Behind, a HttpServlet provided by the framework is used but we don't need to worry about it because it's ready to be used. One of their main goal is handling all boilerplate, complex and repetitive code to allow developers to have a flexible way of designing their web applications.

For example, JSF 1 (which is not very recent) allow to use JSF backingbean to map a JSP view to a almost classic Object Java and not a rigid servlet with just a single doGet() method to handle our needs. In this backingbean, you can add any methods as in a classic java class and you call these methods from your JSP in a Java classic way : myBean.myMethod().

Most of Java EE UI frameworks (SpringMVC, GWT, Struts 2, etc...) allow to do that.

davidxxx
  • 125,838
  • 23
  • 214
  • 215
  • thanks, but in this case I avoid to use any framework. – newUser.java Aug 21 '16 at 09:45
  • In this case, you must re-invent the wheel (which is time consummer) or choose the less bad design according to a simple and precise logic rule to have a correct design. For example, use the `doGet()` method with dispatching to a classic class java which will be a more flexible controller with as many public methods as needed to handle related use cases and a use a `doGet()` without dispatching to handle a single use case when the use case is isolated. – davidxxx Aug 21 '16 at 10:03