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 Preferred Pattern (Industry Standard?) 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 "Preferred Pattern (Industry Standard?)" Watch "Preferred Pattern (Industry Standard?)" New topic
Author

Preferred Pattern (Industry Standard?)

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

I have been doing some reading today on J2EE Patterns such as Command Pattern, Font Controller Pattern, Servlet Controller, JSP Controller, etc. And while some will say one is better than the other, I have not been able to find anyone or anything that states which one is preferred or the best way.
Is this to say that there is no "best" pattern? It seems like all the J2EE Frameworks (STRUTS, WebWorks, etc) are using the Front Controller Pattern.
Personally, I have been testing out some Front Contoller implementations of my own. I have also tried a Base Servlet Controller pattern in which I create a Base Servlet for all my Servlets to subclass. And I have also tried the plain jane servlet for every request approach.
So is there really an industry standard as to which pattern is best? Is it something that is best determined by the application itself? Is the choice of pattern something that is unique to each developers own style?
Thanks for any information.
[ December 31, 2003: Message edited by: Gregg Bolinger ]

GenRocket - A Test Data Generation Platform
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

I haven't really seen that any one pattern is The One. The Front Controller is very prevalent (as you noted) because of the pervasive use of Struts and other frameworks based upon this pattern. As you know from my other posts, I have my very own Front Controller framework that I use for all my web apps.
In my previous job the company created lots of little web apps each of which did their own thing. Most used the servlet-per-page approach.
In my previous previous job, it was early enough that no one knew what the heck they were doing and the app was a non-servlet Model 1 (JSP-centric) approach with all the hell that created.
I like this question. It'll be interesting to see what patterns other web application authors are using.
bear


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
Watch out, looking for a certain pattern is like falling into quick sand.
In my mind, patterns defininitions are a good tool to communicate how you have done something. I don't think you should pick a pattern and then design you app.
Think about what your app needs to do, decide on the best technology to do it and then find that pattern that fits what you have done.
Your requirements are your requirements and no one else's. Fulfill your app's requirements and then use the pattern that outlines your solution to communicate the basics of the how.
In my mind, picking the Round Peg pattern for a Square Hole problem for the sake of using the Round Peg pattern can be very counter productive. Figure out you have a Square Hole, create a Square Peg and document that you have used the Square Peg pattern.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15629
    
  15

The word "best" makes me gag. Very few things in life have only one solution, and especially when it comes to software (just ask the Perl crowd!).
Ask yourself:
1. What are my particular practical (not theoretical) needs. Choose as many from the following as apply and add others as needed: Speed of development, ease of maintenance, ease of support, performance, reliability, interoperability.
2. How do the solutions you know of fit within that framework (yes, this is a form of linear programming)?
3. Realize than within 2 years (and probably within 6 months), something newer and "better" is going to come along. Will your chosen solution be likely to make the transition, if needed?
4. Are you one of those few remaining people who have a "permanent" job, or is it likely you'll be working somewhere else in 2 years and the amount of sweat you spend choosing a solution won't matter anyway?
OK, so #4 is pretty cynical, but if you're going to get ulcers over the decision-making process, keep that in mind. I'm not suggesting you short-change anyone, just to consider value delivered vs. value received.


Customer surveys are for companies who didn't pay proper attention to begin with.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

I guess to extend the discussion in this thread something that should be discussed is what specific design patterns do for you. For example, what would be the benefit, if any, of using a single Front Controller over a Servlet per request approach. As far as a functional App, either would work. But there has to be a reason one might choose one over the other if both can do the job.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

While I completely agree with "don't use a pattern just because it's cool", I think Gregg's question was "is there a best Round Hole pattern, for the Round Hole problem?". Did you read otherwise, or are you just making a general (and very valid) statement about falling into The Pattern Trap?
bear
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

Originally posted by Bear Bibeault:
While I completely agree with "don't use a pattern just because it's cool", I think Gregg's question was "is there a best Round Hole pattern, for the Round Hole problem?". Did you read otherwise, or are you just making a general (and very valid) statement about falling into The Pattern Trap?
bear

That was more or less my intent, but I am not discouraging the current conversation. But as my previous post stated, I would like to discuss the best round hole solution for the round hole problem as in choosing one over the other when both would suffice.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

Not to say the I think the FC pattern is the "best" approach for all web apps -- I completely agree with previous posters that there's rarely a "best" approach to any general problem. Each problem requires evaluation to determine the applicability of an approach to that problem -- I merely point out that I've found that the FC pattern has been successfully applicable to the web apps I have worked on.
The FC for my web apps gives me a number of concrete advantages over the servlet-per-page approach:
1) Common processing is factored out into the FC
2) There's a single point to add things you want to do on each request (like authentication policy checking)
3) Single point of debug
and so on.
My first attempt to achieve (1) was to create an abstract base servlet to factor out common processing of the servlets-per-page. But while this reduced the amount of code in each servlet, they all still had a lot of repeated code in them to call the base methods. By creating an FC, my per-page actions are able to contain just the per-page code rather than boiler-plate.
bear
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
The trouble is with this thread, that there's lots of arguing about "pegs" but there has been no more detail about what this "round hole" is!
All the approaches mentioned have their advantages and disadvantages, and each is more appropriate in one situation than another. To make any sort of decision we need to know what you need to achieve, and what the limitations or expecvtations of the solution might be.
For example, if your web application is just a throwaway single-page form-and-handler kind of thing, then the much-derided JSP model 1 is fine. There's simply no point in implementing servlets, actions controllers or any of that stuff. To justify more time invested in (building, finding, configuring, choosing, ...) anything more complicated, there needs to be a reason why it will benefit the solution.
So let's turn this back on you, Gregg: What situations can you concieve of where one of these approaches might be "best" ?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
I was making more of a general 'watch out' type of statement. Many times (more than not) I've seen people I work with want to use a certain tool/solution for the sake of using it without regard to what it really gives us and if we have already solved that problem.
As far as what is the best FC/MVC solution, the answer to that depends on who you ask. I suspect that STRUTS is the most popular, however I can think of about 6 different APIs to use off the top of my head. They are all valid, they all work, it's mainly a choice of preference, what does the staff know and which do you want to get 'locked' into.
There are several solutions that allow for one Servlet Super Class to be the controller if additional functionality is needed. You can either override service(HReq/HRes) in your Base Class (calling super.service()), or override doGet/doPost to call a method that does base processing. I almost prefer service as it does not require any explicit coding except that all subclasses extend the super class. It may not be common to override service, but it is not declared final and is declare protected (vs. private), so it was designed with that in mind.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

Originally posted by Frank Carver:
The trouble is with this thread, that there's lots of arguing about "pegs" but there has been no more detail about what this "round hole" is!
All the approaches mentioned have their advantages and disadvantages, and each is more appropriate in one situation than another. To make any sort of decision we need to know what you need to achieve, and what the limitations or expecvtations of the solution might be.
For example, if your web application is just a throwaway single-page form-and-handler kind of thing, then the much-derided JSP model 1 is fine. There's simply no point in implementing servlets, actions controllers or any of that stuff. To justify more time invested in (building, finding, configuring, choosing, ...) anything more complicated, there needs to be a reason why it will benefit the solution.
So let's turn this back on you, Gregg: What situations can you concieve of where one of these approaches might be "best" ?


I would think that any "round hole" should be implemented using the best design possible. But again, what is the best design. The fact is that any application has the possibility for growth. Even that "throw away app". So why not design it the best way initially and save the headaches later on? So how do you determine this?
To answer Franks question though: I would say a web app that processes forms, talks to a DB, generates reports. For the sake of specifying a "round hole" lets just say Forum Software like MVN or UBB.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

I was making more of a general 'watch out' type of statement.

I am 100% with you!
bear
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Kenneth Robinson wrote: I was making more of a general 'watch out' type of statement.
Oh, I agree with that. I make plenty of those myself
Gregg wrote: I would think that any "round hole" should be implemented using the best design possible. But again, what is the best design. The fact is that any application has the possibility for growth. Even that "throw away app". So why not design it the best way initially and save the headaches later on?
I thought it would be something like this that drove the initial question.
In my experience, though, trying to (over?) design for an unknown future is almost always a mistake. In my consultancy work I've been called in to work on lots of projects with problems, and none of them ever had "not enough code". The invariable problem is that the initial fubction of the code was swamped in frameworks and speculative designs, then the future requirements went a different, unanticipated, direction.
For me the "best" design which will save the most headaches later on, is simply the one with the least. least code, least config files, least dependencies, least deployment process, least steps in the build, least to throw away when you know more.
So yes, if all that is needed right now is a single JSP, that's what I recommend making right now.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Preferred Pattern (Industry Standard?)
 
Similar Threads
Front Controller
Action Class as Adapter pattern
ServletContext, again
To combine or not..That is the question
Any disadvantages of the struts framework.