• 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

Service-2--Worker vs. Dispatcher View

 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From studying the Core J2EE Patterns book, I understand the difference in the implementation of these 2 patterns. The only thing I do not find is when it is best to use one pattern over the other.
What kind of project or requirements favor pushing the content retrieval to the view with the Dispatcher View pattern as opposed to putting more responsibility in the Controller/Dispatcher?
For example, if you were building a more complex GUI interface using custom tags, etc, would the Dispatcher View make more sense? Or if you needed more dynamic flexibility during runtime, would you design that better in a Service-to-Worker pattern?
This question has been bugging me for a while..
Thanks
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think user the Dispatcher view pattern goes against the concept of having a thin client, and hence must not be used in a web environment. Maybe a non web based application where we wish to make the client more intelligent might be a likely candidate for using the Dispatcher View pattern. Maybe an app where the strategy for getting content is part of client logic. I tried thinking but could not think af any concrete scenario.
Parag
 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I actually don't use either. I guess my version is closest to Service-To-Worker, though. My servlets act as both controller/dispatcher.
As a rule of thumb, I put all domain objects that do processing (algorithms, database access, remote connections, rule parsing) in stand-alone java classes, and ONLY the controller knows about them. I post to servlets, they package the parameters and ship 'em off to the domain. When the domain returns with results, I then figure out which view to show or if I need to report an error. I just take the result data, package it into the request using setAttribute(), then forward to the JSP view that extracts the data and displays it. The way I do it, the data doesn't have to be a JavaBean (Helper). More commonly I'll have Hashtables or Lists of Hashtables (each hash in the List representing a 'row' of data). This allows me to change the data format without requiring the JSP to recompile because I've changed a bean class.
Once the view has the data, I have no problem using custom tags/taglibs to do view processing (such as text formatting, table-ization, color-ization, etc), but at that point I disallow any and all domain processing. This way I can rewrite my view without affecting any domain processing activity. This increases robustness and debuggability.
Part of the reason I let the domain objects handle all the processing and responsibility is that the separation allows for much more flexibility, but I also think it's better perfomance-wise. Using JSPs and taglibs adds overhead that I'd rather not incur. Also, you can ship your domain off to an app server, or split it out into multiple app servers and let your controller servlets or other mechanism farm out the work in a balanced way.
My recommendation is to figure out what you like best by trying both out! Or try mine! :-) I've a big believer in throwaway test prototypes as a learning tool. You can simulate database and remote system interaction and figure out how the patterns really work without dealing with setup issues.
To finish up, I'm against content retrieval from JSPs. It's plain awkward and it's difficult to do many of the things you can do in plain java, like use inheritance and interfaces, unless you stick it all in taglibs, but that's actually more work than writing plain java, and more difficult to debug! JSPs are horrible when you're trying to debug anything. BTW, whenever you start your project, make logging and error-handling a BIG priority! Here's one last thought - if you put all your processing in plain java classes, you can use the same code to serve not just servlets, but applets, applications, or other remote services! Anyway, I like to keep things simple and flexible, so avoid undue complexity!
Good luck, and let us know what your research leads you to!
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic