Yes, getters/setters are generally 'evil', but sometimes unavoidable. Just because the get/set idiom is popular doesn't make it good. First, the term POJO originally meant "Not EJB". The way people have been using it lately means "Java Bean". One of the real weaknesses of Struts-1 was the ActionForm. It was really a Struts-specific TransferObject (TO), but being Struts-specific means that you shouldn't put it into your back-end processes, so you had to make another TransferObject for the back end. These two classes were just about identical which made for duplicated code, a primary "Design Smell". Furthermore, since all the properties were exposed as Primitive types and Strings, they made for very fragile code, hard to maintain, etc. Now with Struts-2, they have done away with the need for the separate TO, but they just moved the requirement for all the getters/setters to the Action class itself. So now it is the Action which is fragile, difficult to maintain, etc. It is certainly vastly better than S1, but still a pretty lame architecture. But ModelDriven almost comes to the rescue. Now the Action can make an object visible to the web pages, and all the getters/setters can be on that object. So the fragility is taken out of the Action, into the model. There are some problems with ModelDriven, but it is pretty good. The problems with ModelDriven include the fact that it is on the stack, and the stack is re-created for each request, meaning that it isn't really a good repository for the data if the processing of a UseCase takes more than one request, for example creating the model is one request, modifying the model is another, redisplaying it is another, verifying the changes is another. You really have to use some hack with the session to make this useable.
Now why are getters/setters evil? I STRONGLY recommend the articles from JavaWorld: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html and http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html?page=2 The author, Alan Holub, knows his stuff. As the preface to his book suggests, he might not be the ideal person to be on a deserted island with, but these articles are full of value. These articles describe the problem and a nice solution. The solution involves the "Builder Pattern" for the Business Objects, with an "Exporter" to create the view layer. Of course, working with JSP, you don't want to have to put the code to build the view inside a long "println" syntax, so some imaginative modification is needed. What I did was to make an Interface with all the objects I might need in my pages: Values, Tables, Trees. Then the exporter provides these objects to the JSP page, and I have no getters/setters at all on the Business Objects (the model), and only a few in the Exporter, which I regard now as a ViewHelper pattern. I make the Exporter available thru the Action class, and now my Actions know nothing about the model, the model knows nothing about the database (the 'Importer' knows that), and the Exporter doesn't expose anything about the Model to the Action or the View. It has become, in essence, a TO. For other view layers, I produce other Exporters, a PDFExporter, a SpreadSheetExporter, etc. - Ray Clough [EMAIL PROTECTED] > ----- Original Message ----- > From: mraible <[EMAIL PROTECTED]> > To: user@struts.apache.org > Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? > Date: Mon, 6 Aug 2007 13:44:16 -0700 (PDT) > > > Also, if you believe getters and setters are evil, what's the solution? Most > of the Java web frameworks I know of today use getters and setters to > read/set values. Are getters and setters evil in your Hibernate/JPA POJOs as > well? > > Matt > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
