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/msg03376.html > then you will like the rest ) > > 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 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/msg30193.html > Or > http://groups.yahoo.com/group/model_struts/message/48 > > > 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/msg30193.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. > > > 2nd: People do not just do Struts. They do JSTL or bean:use. > > 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. > > 4th. You should be able to unit test the bean ( in a console) before you > use it. > > 5th. Only simple things are practical. On a large project people get > lost in the woods. > > 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 > > 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. > > 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. > > 9th . I realize you design the engine. It just drives better this way in > the real world. > > Summary: > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg30193.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]>
