File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes To combine or not..That is the question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "To combine or not..That is the question" Watch "To combine or not..That is the question" New topic
Author

To combine or not..That is the question

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

This is how I am currently doing things.

  • I have a servlet called SomeFormView which, for the most part, just forwards to a corosponding JSP called SomeForm.jsp. SomeFormView may or may not do some initial work prior to forwarding.
  • I have a Servlet called SomeFormAction which processes the submitted request from SomeForm.jsp.

  • So my question is, should I keep the servlets seperated as they are now, or would there be any benifits, drawbacks, smack me in the head this is stupid, to combining those servlets into 1 servlet which initially forwards me to my view, but then also handles the request when the form is submitted.

    My initial thinking is its a good idea to keep them seperated for readability reasons. What do you think?


    GenRocket - A Test Data Generation Platform
    Dale DeMott
    Ranch Hand

    Joined: Nov 02, 2000
    Posts: 515
    Many people like a single servlet design where everything goes through a single servlet. Others like to cut up parts of the system by servlet. Personally if I were programming a small system, I would make the system only have 1 servlet. The servlet would then process the action performed by the user and then redirect the program flow through maybe a command factory for processing, then return back and serve up the new data to the next jsp page. Just my 2 cents worth.


    By failing to prepare, you are preparing to fail.<br />Benjamin Franklin (1706 - 1790)
    Gregg Bolinger
    GenRocket Founder
    Ranch Hand

    Joined: Jul 11, 2001
    Posts: 15286
        
        6

    Originally posted by Dale DeMott:
    Many people like a single servlet design where everything goes through a single servlet. Others like to cut up parts of the system by servlet. Personally if I were programming a small system, I would make the system only have 1 servlet. The servlet would then process the action performed by the user and then redirect the program flow through maybe a command factory for processing, then return back and serve up the new data to the next jsp page. Just my 2 cents worth.


    But I won't have just 1 servlet. I would either have 10 or 20 depending on if I combined the 2 into 1 or not. So that is what I am talking about.

    Thanks.
    Dmitry Melnik
    Ranch Hand

    Joined: Dec 18, 2003
    Posts: 328
    My initial thinking is its a good idea to keep them seperated for readability reasons. What do you think?

    I think that it's quite possible to separate the functionality, and get similar readability without creating separate servlets. Is readability your only reason?
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60041
        
      65

    I would make them separate as they do entirely different things. Even though you are thinking of them as associated with the same page, one is preparing the page for view, the other is processing the results of the page. Related, but different.

    Also, flexibility is gained by keeping them separate. Take for example a login function. The "login form" could appear in may places within the site (a welcome page, a timeout page, and so on). By making sure that the login processing servlet is not tied to a particular page, it can be reused no matter what page the login is submitted from. Each page is free then to have its own 'prepare' servlet that's appropriate for that page.

    Keeping things as decoupled as possible will make your world a rosier place where you'll feel warm and fuzzy enough to hug strangers on the street.
    [ July 22, 2004: Message edited by: Bear Bibeault ]

    [Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
    Gregg Bolinger
    GenRocket Founder
    Ranch Hand

    Joined: Jul 11, 2001
    Posts: 15286
        
        6

    Thanks Bear.
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60041
        
      65

    Small hijack:

    Personally if I were programming a small system, I would make the system only have 1 servlet.


    This is called the Single Front Controller pattern and I use it for all my web apps, be they small or enterprise-sized. I think its utility increases with larger web apps.
    Gregg Bolinger
    GenRocket Founder
    Ranch Hand

    Joined: Jul 11, 2001
    Posts: 15286
        
        6

    Originally posted by Bear Bibeault:
    Small hijack:



    This is called the Single Front Controller pattern and I use it for all my web apps, be they small or enterprise-sized. I think its utility increases with larger web apps.


    This could turn into an interesting conversation, albeit a hijacked one.

    I read this and went on my way as usual thinking, yeah, Bear's right. But then I started thinking about it. So here is the situation I am thinking...

    You've got 1 controller servlet (like in Struts, WebWork, etc) and it takes incoming requests and uses some file or whatever to map them to the appropriate action or view.

    But here-in lies my quaffle with this. Lets say you have a page, SomeForm.jsp which contains some dropdown lists that need to be populated from a database. So in your controller servlet you send this request to a preliminary class that gets this information and puts in the request or session or context, or whatever then forwards on to SomeForm.jsp. Then SomeForm.jsp has to be submitted so it goes back to the Controller which then finds the mapping for the appropriate Action.

    Guess what, you still have 2 files. You can call them Actions or you can call them Servlets or you can call them BearsCoolClassesForDoingSomeWork, but it seems the same to me as just writing 2 servlets like I am doing.

    Ok, so I realize I haven't built any large enterprise level applications. And I realize that I am far from an expert at J2EE. But the process I described, if somewhat accurate (at least it is with Struts), doesn't seem that beneficial to me.

    So the web.xml file gets slammed with Serlvets and Servlet Mappings. Is this really a problem? I mean, you are either looking through web.xml or you are looking through some mapping file to figure out what the hell is going on.

    I know this has been discussed to death. I guess I'll figure out the benefit of such a design when something bites me in the ass someday and I'll say "Damn, I should have used a Front Controller".
    [ July 22, 2004: Message edited by: Gregg Bolinger ]
    Dmitry Melnik
    Ranch Hand

    Joined: Dec 18, 2003
    Posts: 328
    Guess what, you still have 2 files. ...it seems the same to me as just writing 2 servlets like I am doing.

    That's right, and that's my point
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60041
        
      65

    The number of files isn't an issue that is even on my radar.

    I like the SFC pattern because my front controller does a lot of work for me, before and after executing the 'action', that I would otherwise have to code in every servlet. Another pattern I've seen for such reuse is to have an abstract base servlet that contains the 'shared' code. Yet another uses servlet filters.

    While these, and any other number of possible patterns, are perfectly plausible, I chose the SFC/Action pattern for my framework and it works really well for me. If I had to pick one major benefit of many I feel that I reap from this decision, it's that my Action classes are almost always just a few lines of code. (Having a strong business layer architecture helps this as well).

    I'm not even going to hint that the SFC is THE pattern to use, I just think that's it's one of the possible good patterns to use that may or may not work with your style of structuring applications.
    Gregg Bolinger
    GenRocket Founder
    Ranch Hand

    Joined: Jul 11, 2001
    Posts: 15286
        
        6

    Originally posted by Bear Bibeault:
    The number of files isn't an issue that is even on my radar.

    I like the SFC pattern because my front controller does a lot of work for me, before and after executing the 'action', that I would otherwise have to code in every servlet. Another pattern I've seen for such reuse is to have an abstract base servlet that contains the 'shared' code. Yet another uses servlet filters.

    While these, and any other number of possible patterns, are perfectly plausible, I chose the SFC/Action pattern for my framework and it works really well for me. If I had to pick one major benefit of many I feel that I reap from this decision, it's that my Action classes are almost always just a few lines of code. (Having a strong business layer architecture helps this as well).

    I'm not even going to hint that the SFC is THE pattern to use, I just think that's it's one of the possible good patterns to use that may or may not work with your style of structuring applications.


    Bear write all this while rolling his eyes at me

    Funny that after I posted that I thought, the number of files probably doesn't matter and it wouldn't matter to me. My Servlets don't contain that much code either. Just the usual doGet and doPost that both call a process method. I could use a base class for that, but it's not that difficult to copy and paste some code.

    However, I do use the ServletFilter but only for security and light logging.
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60041
        
      65

    Bear write all this while rolling his eyes at me


    Never! I do, in fact, admire your obvious thirst for varied opinions in order to decide what would work best for ya!
    Ken Robinson
    Ranch Hand

    Joined: Dec 23, 2003
    Posts: 101
    Why, why, why in web programming is creating a 'Single Front Controller' considered a good thing while in all other aspects of programming a superclass is the way to go? Why not leverage what is required to be there?

    Bear, you outline two things, the ability to have some front controller do common processing and then forward to the correct resource. How is this not what you get out of the box with J2EE?

    Each resource is a servlet. Use the <servlet> tag to register it and <servlet-mapping> tag to bind it to one or more URLs.

    If you want common processing, create an abstract servlet class that all Servlet inherit. Override the service(HttpServletRequest, HttpServletResponse) method to do the common work. You only have to call super.service() from your superclass and the subclasses need not do anything.
    [ July 23, 2004: Message edited by: Ken Robinson ]
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60041
        
      65

    create an abstract servlet class that all Servlet inherit.


    Yup, I had already pointed out that that was another perfectly viable pattern. Just not the one I chose for my own use.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: To combine or not..That is the question
     
    Similar Threads
    Web App. Question
    request
    how to send session info from Applet to servlet?
    Preventing users from seeing old data using their browser back button
    JSP Bean,not able to work my first bean