Um, did I miss something? This posting seemed to come out of the blue (I don't have any previous messages with this subject line), but also appears to be the result of some lengthy discussion.
A few comments (totally without context, of course :) interspersed below... > -----Original Message----- > From: Struts-dev Newsgroup [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 11, 2002 11:25 PM > To: [EMAIL PROTECTED] > Subject: Re: FormBeans ... as an Interface. > > > Subject: Re: FormBeans ... as an Interface. > From: "Vic C." <[EMAIL PROTECTED]> > === > Vic C. wrote: > > OK so some people think I should preach FormBean as a View > and not as a > > Model, so here is ... why I do recommend FormBean as Model and you > > should leave the door open. > > ( If you buy this > > > http://www.mail-archive.com/general%40jakarta.apache.org/msg03 > 376.html > > then you will like the rest ) I see nothing in the referenced message that has anything to do with form beans (or Struts at all). I do see a message that claims that EJB is a technology sometimes used inappropriately, and which can overly complicate a design. I agree with that. But EJB and Struts are entirely different - and independent - technologies. The connection is ... ? > > > > Like I said, the cool thing about Bazaar vs Cathedral is that if a > > better way is found, it is not a big deal to do it they "new" way. > > FormBeans ... as an Interface is an old issue. I don't buy this, context or no context. Even in the cathedral model, new ways can be chosen over old. I think people get confused because they think they have to wait for "the new way" to come out of the cathedral. Not so. You're just as free to do things your own "better" way in either the cathedral model or the bazaar model. But I'm curious about how this comes into a Struts discussion... > > > > I used to do it the way documented: 2.6 Accessing > Relational Databases > > public ActionForward > > perform(ActionMapping mapping, > > ActionForm form, > > HttpServletRequest request, > > HttpServletResponse response) > > { > > javax.sql.DataSource dataSource; > > java.sql.Connection myConnection; > > > > try { > > dataSource = servlet.findDataSource(null); > > myConnection = dataSource.getConnection(); > > > > //do what you wish with myConnection > > } catch (SQLException sqle) { > > getServlet().log("Connection.process", sqle); > > } finally { > > > > //enclose this in a finally block to make > > //sure the connection is closed > > try { > > myConnection.close(); > > } catch (SQLException e) { > > getServlet().log("Connection.close", e); > > } > > } > > This implies JDBC in Action and in Model and in other places. > > > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg > 30193.html > > Or > > http://groups.yahoo.com/group/model_struts/message/48 > > Sigh. One of the dangers of documenting anything is that people will read more into it than was intended. This particular case is a wonderful example. The intent is to show how databases can be accessed. That is what the section is about. It was not supposed to be part of a best practices guide to say this is how people should structure their Struts applications. The problem is one of providing enough context that a code fragment makes sense, but not so much that the reader is burdened with learning an entire application design just to understand a few lines of code. Should we really have to provide caveats everywhere we have code fragments, stating that the documentation is not a best practices guide, or a web application design manual? I hope not. > > > > Clients are saying why should I do Struts when I can do ASP > w/ ADO. When > > they do "J2EE" they use the db tag and want to use the SQL > tag so single > > tier. > > They are not always cable do implement design patterns. > They find them > > complex. When they do a BO and a DTO and etc. they get lost. > > > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg > 30193.html > > makes my case, it ends up a PetStore (since most of the > paterns were > > there to speed up slow EJB - > > Conculsion: The solution is in the middle, simpler than > PetStore and MVC > > and not single tier. This is the sweet spot. > > There are not roles and tiers or valid theory of re-use. > MVC should be > > presentation, application and data base, simple model 2. > > See struts source file doc folder model2.gif. There are no > BO or DTO or VO or... Struts is an > > alternative to PetStore. I'm really not sure what the point is here. Good design for large web apps is complex, there's no getting around that. But teaching the value of separation of concerns should be sufficient to help people understand why single tier is a bad idea for more than very simple and/or throw-away apps. You don't have to understand design patterns or EJB or complex architectures to understand that. The last statement is very puzzling - "Struts is an alternative to PetStore". Struts is an application framework. PetStore is a demo application. They are not even close to he same thing. How can they be alternatives? > > > > > > 2nd: People do not just do Struts. They do JSTL or bean:use. And your point is ... ? > > > > 3rd: People use beans for Swing event notification, or for SOAP. > > JavaBeans are great. And 2 JavaBeans are worse than one. > With a single > > JavaBean you only have to import Struts, no big deal. Claiming that "2 JavaBeans are worse than one" is rather a sweeping statement. So I should just implement my entire app as a single JavaBean, then? ;-) > > > > 4th. You should be able to unit test the bean ( in a > console) before you > > use it. Good idea. Not always possible, though. > > > > 5th. Only simple things are practical. On a large project > people get > > lost in the woods. That's up to the architect / designer / tech lead. If people are getting lost in the woods, then that person (or perhaps it's more than one person) is not doing his/her job properly. Good designs, well documented, should be easy to understand. That's part of what makes them good designs. > > > > 6th. Show me! There are no samples. WebPIM is a sample DB CRUD with > > master detail on SourceForge. More sample coming. Like now > do you master > > detail on a single page updateable? Show me the code, not PetStore Context, please? Puzzled again ... > > > > 7th. Corporate developers say they have 3 years of Java. > More like 6 > > months. They can't do the complex design patterns. > Developers of Struts > > can. Corporate developers don't have to do complex design patterns any more than anyone else does. Are you claiming that MVC is a complex design pattern? I don't think so. As long as it's explained well, and its use justified simply, then even junior developers can grok it - at least in my own personal experience. Case in point: On my last big project, I had around 10 developers working on the same Struts app. They were of all levels - entry level through principal engineer. None of them, other than me, had any idea what Struts was all about when they started, and the more junior people had never heard of MVC. It took only a short time for them to understand what MVC was all about, and why it, and hence Struts, was a good idea for the size of project we were undertaking. With appropriate assignment of tasks, every one of them was productive throughout the project, and most of them still know next to nothing about "complex design patterns". The app, by the way, has been shipping for almost a year now. > > > > 8th. The point of design patterns and OO is productivity > via reuse. > > Some people do design patterns for the sake of doing a > design patter, > > and not for reuse. That will always be the case, and there's nothing anyone can do to stop it, I'm afraid. It reminds me of a guy I used to work with who was determined to use every last feature of C++ in his project... > > > > 9th . I realize you design the engine. It just drives > better this way in > > the real world. OK, I'm all out of context now, so I'll shut up. ;-) -- Martin Cooper > > > > Summary: > > > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg 30193.html > or db tags or.... A sweet spot in the middle. > > > Also... DynaBeans violate some presentation, application and data base > clear separation principles. The view should not know much about data. > Neither should the action. > > Anyway, when client's hire me for a good practice, this is what I > recommend. > Yes you can build the app the other way. The question is which will let > you finish faster, and which will be easier to maintain. > > I urge you to keep the door open to an un predicted alternative. > > > Vic > > > > > > > > ------------------------------------------------------------------------ > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
