A few notes from a few responses:
> > 1) "Object explosion" for large sites--1-to-1 mapping of > URLs to objects can > > lead to hundreds of small classes. It really bothers me that > Struts > > encourages this kind of situation. Although the > DispatchAction helps a lot. > > > > 30 years of professional software development experience leads > me to > believe that 738 simple, easy-to-understand, separately > maintainable. > single purpose classes that follow a standard design pattern > (in this case > the GoF "command pattern") are a much better investment that > one class > with 738 branch points -- unfortunately very common -- or zero > business > logic classes because the business logic is intermixed with > the > presentation (a malady that is far to common in webapps). > As Dave Peckham pointed out, you can have multiple pages/requests map to the same Action class. The question you have to ask in doing this is this: where do I stop? You do not want the entire app, but only a specific set of related functions mapping to the same Action class. When we did this at my shop, we had about 20 different possibilities across 5 pages. This resulted in a horribly long if/else block, and to make it more complex, some of the "ifs" would have to execute other "ifs" (e.g., if it comes in blank, do the same as if it came in as read unless parameter x is null, etc.). To address this, I broke the "ifs" into individual methods, then simply used the incoming "action" parameter and, using reflection, executed the appropriate method (null or "" mapped to a default method). This is a much more OO structured approach than an if/else statement and allows for cross-method invocation. > > 2) Meaningless method signatures, like execute(Mapping, > Form, Request, > > Response). All the methods look the same, regardless of what > data they're > > actually expecting. This often makes it necessary to go into > the Java code > > just to figure out what data a method uses. Not to mention > losing > > compile-time type checking. > > > > My experience has been that the benefits of "sameness" far > outweigh these > costs. In particular, type checking is something that is > easily toolable > - you don't have to have the compiler do it for you. > > Speaking of tools, have you noticed the number of tools that > are starting > to take models of a business application, and generating them > based on > Struts? That can happen because the basic interactions are > very simple, > and very well defined. > It also allows for a much simpler and more efficient subclassing. Instead of the subclass having to acquire the resources from multiple places, it has them all passed into the method. > > I have been doing front-end web development since 1996, and > doing it in Java > > since 2000, and in all that time I have never built a > presentation tier that > > I would consider both large and clean. It just seems like as > websites get > > bigger and bigger (the site of the company I'm working at > has 738 at the > > moment) there is no way to avoid "throwaway" code (i.e. at > least one method > > per request that does little else but service that request). > I got so sick > > of it that I am no longer in web development, instead I > concentrate on the > > backend transaction processing. > > > > There are those of us who have to write webapps anyway, and > don't get that > option. And, in reality, web development is *much* cleaner > than GUI > programs -- have you ever looked at someone else's code based > on Swing, or > MFC, or ...? That's how I ended up on the web app development > in the > first place, instead of GUIs :-). > I heartily agree. I've done enough GUI programming to know I never want to do it again. I am currently working on a major application rewrite from a client/server base to become a webapp and the ease and speed of which web screens can be designed and implemented is amazing. Using intelligent DHTML allows for our webapp to be fully keyboard driven as well as mouse supplemented, thus retaining the keyboard speed of a green screen or client server app. The one thing GUI apps still have over webapps is the ability to more dynamically respond to the user without having to send/receive info to/from the server. There are ways around some of this, but overall it is not quite as nice as a GUI for some things. On the whole (anybody see Austin Powers 3? I can't say on the whole without cracking up now!!!), web programming is so much better than true GUI programming that I'll never go back. And by the way, everybody on my project is responsible for programming the front end JSPs through the back end EJBs. I'm amazed when people say that there are shops that can completely segregate the two tasks (I can see some segregation, but not total unless it's a very large and advanced shop that can actually divide the workflow that well -- a concept that I still find difficult to believe). __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
