Subject: Re: Java Pro Article: Thought I have form beans figured out... From: Vic Cekvenich <[EMAIL PROTECTED]> === I agree that MVC segregation and separation is key to productivity; and key to good design. Combining or omitting one is not good for web apps.
[EMAIL PROTECTED] wrote: > > > From reading this, it seems author is interested in promoting an > architecture designed to eliminate the advantages of object oriented > development and make maintenace a hair-pulling experience. > > Combining the FOrm bean, MOdel, and COntroller components together results > in what I'll call a FoMoCo bean - or as the author says, "a model that > incorporates dispatcher and view characteristics". Like I said, FoMoCo. > > The FoMoCo bean approach has two major drawbacks. > > - Maintenance of the application becomes much more difficult with a > greater liklihood of bugs being created. > - Building a large application with multiple developers becomes much more > difficult as it is impossible to break the different layers apart for > different people to work on. > > For example, imagine you are building an application and the database > schema is changed. Several tables are reorganized, but the data is similar. > Imagine this data is desplayed on several pages in the app. Or imagine > you've found data problems and need to add code to catch bad data if it > comes. Here's the impact: > > - Using Struts as it is designed, you would do the following: > > - Modify the Model components (Entity EJB's or DAO objects if > you're not using EJB's) to reflect the new queries/code required to get the > data. > - Make no changes to how you populate the form beans in the > action servlets. The changes have been isolated into the data access layer. > - The presentation layer is untouched. None of the pages/form > beans using the data need to be updated. > > - In summary: Change DAO or EJB, Don't change controller, form > bean or jsp for any of the pages using the data. > > - In FoMoCo, you'd do the following: > > - Go into each FoMoCo bean on every page needing the data, and > modify the code in each. > - Since the code in each FoMoCo bean has set/get properties, JDBC > code and/or EJB calls the changes may be complicated. > - This spreads the changes through more class files - that are > each more complex and prone to bug creation. > - Since the FoMoCo's may have been written by different people, > it's difficult (and error prone) figuring out every place that needs to be > changed. > > FoMoCo eliminates all the benefits of good object-oriented design. > > In addition, the author's approach of packaging the persistance mechanism > in the form bean is misguided at best. This means you'll have to use the > same form bean on every page requiring access to the persistence mechanism. > (i.e., every page in your app potentially). Please seperate this logic out > of the form bean and put it in a User bean (or something similar) that is > stored on the session context. > > Calling this approach to managing persistency "controversial" is > appropriate. It's controversial like recommending a sick person be given "a > good bleeding". > > One thing the author did accomplish, however, was his stated goal to " > further cloud the issue". > > > FWIW - > Kevin > > > > > > [EMAIL PROTECTED] on 04/16/2002 05:34:40 PM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > cc: > Subject: Java Pro Article: Thought I have form beans figured out... > > > > > Greetings: > I have been following this list for a while now and it seemed fairly > clear > to me what some of the options for using form beans are. > I know that Struts does not force you to do to much it seemed that the > overriding theme was to try keep form beans ignorant of the datasource. > The new Dynabeans appear to carry this a step further. > > So I raised my eyebrow when I read: > "In my example I'll further cloud the issue by, perhaps somewhat > controversially, > packaging the persistency mechanism in the form bean. " > > and: > " EJBs are wonderful creatures, but they can be cumbersome to use with JSP. > If the EJB is embedded in a form bean, much of this awkwardness > disappears." > > > > Are there any opinions on this? > > > > > Snippet from the Java Pro Article: > "In my example I'll further cloud the issue by, perhaps somewhat > controversially, > packaging the persistency mechanism in the form bean. > Technically a persistent copy of the bean's data is a view, > so now we have a model that incorporates dispatcher and view > characteristics, as > well. > This would seem to negate the reason for having a framework like Struts, > but this design has a couple of redeeming features. > > First, because the validation and SQL code are heavily dependent on what > properties the form bean possesses, > it's easier to maintain them as a unit. Because we are only interested in > the > form bean's properties here, > the "heavy" dispatcher and view components are still safely isolated. > Secondly, when used with the html tag library, the form bean can contain > other > objects, which can be referenced using "dot" notation. > This is a great convenience when working with predefined objects because > Java doesn't support multiple inheritance. It avoids the tedious manual > effort > of > writing form bean get/set logic for each field in of each internal object. > > The convenience is multiplied even further when your inner object is an EJB > normally a very cumbersome object to reference in a JSP page. > EJBs are wonderful creatures, but they can be cumbersome to use with JSP. > If the EJB is embedded in a form bean, much of this awkwardness disappears. > Furthermore, this separates the controller and model, and the persistency > view > aspects are reduced to almost nothing, > because the EJB container handles persistency details for us. > Thus, the form bean becomes almost a pure dispatcher and all's right with > the > world again. > > Well, mostly right. An EJB with lots of properties carries a large RMI > overhead > if it is updated on > a per-property basis the way that the ActionServlet normally does for form > beans. > For high-demand applications, it's better to use the EJB 2.0 local > interface or > to front the EJB with a traditional > JavaBean (some prefer a Session EJB) and pass that bean to an > updateAllProperties() business method in > the entity EJB. That lets you batch up the updates into a single RMI call." > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > --------------------------------------------------------------------------- > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > --------------------------------------------------------------------------- > > > -- > 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]>
