• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Preferred Pattern (Industry Standard?)

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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" ?
 
Ken Robinson
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


I am 100% with you!
bear
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic