I would say no, it's no more acceptable (acceptable being a relative term of course!).
An EmployeeVO, presuming that is an object passed form the control layer to the model layer, still needs to know about something in the view layer, the ActionForm. Hence, it's not really any better. In reply to Rick's original post, I echo the thoughts of others that passing an ActionForm out of an Action to a delegate is generally a bad idea, and certainly is not in keeping with the original intent of an ActionForm, nor in what are generally seen as the best practices of the time. Passing the request is kind of a separate question, but just as undesirable in my opinion because it ties your model to the presentation mechanism. What if someone comes along and wants to take your web-based application and create a Swing front-end for it? Another good reason to not pass request around is that your business delegates become harder to unit test because now you have to deal with mock request objects, or maybe even a whole mock servlet setup (I've seen session passed to business delegates too). I believe Rick knows when he is breaking the "rules" and consciously chooses to do so :) That's acceptable because he understands the consequences and can intelligently make the decision. It's important though that new developers understand not only what things are frowned upon, but also WHY they are frowned upon. I can speak from experience when I say I haven't always followed best practices, sometimes because the situation warranted, but also sometimes because I didn't understand the reasoning behind the practices and hence wasn't convinced to follow them. Best practices are best practices because people tend to agree they have more benefit than other approaches in most cases, and that is the case here. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, July 12, 2005 12:37 pm, Brady Hegberg said: > Rick sent the example code below to an user earlier and I was just > wondering. Would it be acceptable to generate the EmployeeVO using a > constructor like: > > EmployeeVO emp = new EmployeeVO( eForm ); > > Would that be considered tying the view to the business layer? It seems > like it would work nicely especially since you could use polymorphism if > you needed to generate VOs from other Forms (ie > AnotherEmployeeActionForm). > > Thanks, > Brady > >> //In Action method: >> execute(...) //or dispatchMethod update(..) { >> //cast to your ActionForm of String properties >> EmployeeActionForm eForm = (EmployeeActionForm)form; >> >> //business POJO with correct Data types >> EmployeeVO emp = new EmployeeVO(); >> >> //easy to take the stuff from ActionForm to VO >> BeanUtils.copyProperties( emp, eForm ); >> >> //Do the update >> yourEmployeeDAO.updateEmployee( emp ); >> } > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
