People like different ways of approaching software design and that's fine. Nobody insists that you like Struts; I'll just throw in a little historical perspective in intermixed responses below.
On Wed, 14 Aug 2002, Joe Cheng wrote: > Date: Wed, 14 Aug 2002 19:57:37 -0400 > From: Joe Cheng <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: concerns about Struts > > Hi struts folks, > > Let me preface this by saying, I haven't played around too much with Struts > but I have used some homegrown web MVC frameworks that work in much the same > way (from a Controller perspective, anyway). So if I am missing something > obvious about Struts, that's why... > > Anyway, I have a couple of concerns with Struts as a controller, > specifically the ActionServlet and Action classes, and would really > appreciate your insight. > > 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). > 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. > 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 :-). > Being a Java/OO purist, I really don't like it when 738 type-unsafe, > throwaway objects (or methods at least) make their way into the Java object > model. I have grown to recognize that large amounts of such code are > necessary in any large website, but if I can help it I would like to keep it > out of the Java source for the above reasons. > And what's the alternative? Any web application needs to solve the same basic problem set: * Accept a request * Convert the input request parameters/cookies/headers/et al to something your programming language can deal with * Based on some aspect of the incoming request, decide what transaction to perform. * Call the appropriate business logic (and if you prefer a single switch statement with 738 branches, we can stop talking now ... you'd be considered hopeless :-). * Transform the result of performing some business transaction into a response that either shows the user what happened and/or sets up their next activity. Show me a better approach than MVC and I'll happily switch. I've never found one. > I have started writing some code that pushes the messy code out of Java and > into an XML file not unlike the struts config file. However, I've only just > begun really concentrating on this problem, and don't have any experience > working with Struts in the real world, so I was hoping to hear some thoughts > on the subject before sinking much more time into it. > One trend you will see happening is less code having to be written. In Struts 1.1, you see that DynaActionForm (talk about wasted code - nothing is more boring than writing a form bean :-), and experimental integration of XML processing pipelines such as the Stxx project. In the future, you'll undoubtedly see additional ways to reduce the amount of tedious steps. But, a word of advice ... get over your aversion to 738 instances of a common pattern ... it will do your presentation tier designs a world of good :-). > Do you agree with my two complaints? If not, why? If so, can you think of > any way to ease the pain and stay within the Struts framework? > No, I don't agree. And not because you don't have legitimate concerns; you haven't made any attempt to show us a better path (indeed, you have said that you gave up on webapp design because you couldn't). There is no perfect development methodology -- everything in life has tradeoffs. Struts has become the defacto framework for serious webapp development in Java because more than a few people find it useful (many thousands of downloads per month). So, it's clearly not just me that understands that the benefits *far* outweigh the costs. > Thanks, > Joe Cheng > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
