I used to do things as suggested by developers, then I found another good way. This is similar to discussion on Struts-dev on forms beans as interfaces.
I do not know what one calls best, that would depend. Let me define good as something that is more scalable and/or easier to develop. Using design patterns when they break a more important pattern, or slow down performance is an anti pattern. One important pattern is MVC. It says that one should be able to reuse the M or the beans in Swing, Excel (via SOAP) etc. Another important patern is that MVC layers allow for Unit Testing and Unit Testing accelerates development. I do unit test of CRUD/persistence of beans in a console app. So “patterns” that take a connection in action are a -1. A bean that delegates to a DAO and a DAO that getsContext() or reads properties for a DataSource(). *So a good practices it so unit test the reusable model, before Struts or Model 1.* The design of beans that is important is that it matches the “contract” of the JSP “requirements”, that it matches its properties and any iterations or relationships on the JSP. That is the important, requirements. So tested model that matches requirements, that could be more important. Using design patterns for sake of using them is not as important to me. Once developers master above (Reuse of Model, Testing of Model, and the requirements for model) business patters emerge, and that is what you want, to focus on business requirements and problem domain and let “Struts” get out of the way. Technology patters of VO to DTO to BO to Action to FormBean are “lesser” patters and people that study design patters or O/R mapping and then look for a business problem to do it with. Then lets say why VO/DTO? Those design patters were originally designed to add performance to potentially slow EJB. If one does not use EJB, then using extra memory per user might reduce the number of users you have per box by using a EJB performance optimization design pattern. Alternative and sometimes good is FormBean = BO. Only one reusable, tested, requirements based bean, simple and perofmant. (of course the bean delegates DAO persistence) (One bean could contain other beans via getBean(), but that is now a business design pattern). Hth, .V Struts Mentor (917) 345 1445 Craig R. McClanahan wrote: > > On Fri, 11 Oct 2002, David Graham wrote: > > >>Date: Fri, 11 Oct 2002 17:14:09 -0600 >>From: David Graham <[EMAIL PROTECTED]> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: RE: Struts forms best practice >> >>Isn't this what the nested taglib is for? I'm not too familiar with it but >>I thought it allowed you to easily nest value beans inside form beans so you >>don't have to copy properties back and forth. >> > > > If you choose to use the proposed delegations (PersonForm->PersonVO), then > using the nested tag library is certainly a reasonable way to do it. > However, that doesn't solve the data conversion problem, nor the scenarios > where there is not a 1:1 relationship between form beans and value objects > (although that can be hidden to some extent by delegating to more than one > VO). The conversion issue is the kicker, in my book. > > No matter how you implement a form bean, a correct application exhibits > the following behavior on things like dates that are displayed in a text > field: > * User types an invalid value > * Page is redisplayed with an error message and *exactly* the > characters that the user did type. > > If your form bean property (delegated are not) is a Date instead of a > String, you can't guarantee this behavior. > > >>Dave >> > > > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
