You're probably right.
So far I have only used it for Strings and numbers for which
no special mapping was required. In this case it was simple to implement.
Michelle
>From: "Sobkowski, Andrej" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Jakarta Struts (User) (E-mail)" <[EMAIL PROTECTED]>
>CC: "'Michelle Popovits'" <[EMAIL PROTECTED]>
>Subject: RE: Design question - Action Form vs Business Delegates/Value Obj
>ects
>Date: Fri, 23 Nov 2001 09:18:18 -0500
>
>Michelle,
>
>thanks, now I got it.
>
>The problem I see with the approach you describe is that it forces all the
>data conversions inside the ActionForm
>
>EmployeeVO
>// the following must be "Date" to make the VO a "business object"
>+getDateOfBirth:Date
>+setDateOfBirth(Date in):void
>
>EmployeeForm
>public void setDateOfBirth(String in) {
> // CONVERT THE IN STRING TO A DATE
> String convertedDate = ...
> getVO().setDate(convertedDate)
>}
>
>public String getDateOfBirth() {
> // CONVERT THE OUT DATE TO A STRING
> Date outDate = getVO().getDate();
> return (convertDateToString(outDate));
>}
>
>Furthermore, the "less typing" advantage is relatively small. You still
>have
>to code all your get/set and still need both Form and VO. And you need to
>add the conversion code. Or not?
>
>I guess that keeping the two totally separate and dealing with the mapping
>via a separate entity is another possible approach. I have written two
>"PropertyMappers" that do the following automatically for all matching
>get/set:
>FORM -> VO
>vo.setProperty(convertFormProperty(form.getProperty()))
>
>VO -> FORM
>form.setProperty(convertVOProperty(vo.getProperty()))
>
>It doesn't deal with validations nor anything else. It just maps forms and
>VOs. I'll be ready to share it with anybody interested as soon as I have
>properly tested it and added more javadoc.
>
>Thanks to everybody, this is a great list!
>
>Andrej
>
>
>-----Original Message-----
>From: Michelle Popovits [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 22, 2001 7:21 PM
>To: Dmitri Colebatch
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: Design question - Action Form vs Business Delegates/Value
>Obj ects
>
>
>Hi Dim,
>
>Your example is similar to my approach with the exception that you are
>still
>duplicating
>methods of the value object inside of the action form. Instead of
>including
>the individual accessors in the form, just include
>the accessor for the value object (see my original example)...much less
>unnecessary typing this way.
>When you need to access the value object properties in java you just cal
>the
>employeeForm.getEmployeeVo().getName() method and when you are in a jsp and
>want to bind the value object property to a text field you refer to the
>property as "employeeVo.name".
>
>HTH,
>Michelle
>
>----- Original Message -----
>From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Thursday, November 22, 2001 5:34 PM
>Subject: RE: Design question - Action Form vs Business Delegates/Value Obj
>ects
>
>
> > Hi,
> >
> > I also agree with Michelle...
> >
> > I think what you are thinking is maybe you could use the struts form
>_as_
> > the value object? imho this would be bad design, as the whole idea of
> > putting the logic in a separate tier is to have it not bound to any one
> > form of presentation. What Michelle is suggesting though, is something
> > like:
> >
> > public class EmployeeForm extends ActionForm
> > {
> > private EmployeeVO vo = new EmployeeVO();
> >
> > public String getName()
> > {
> > return vo.getName();
> > }
> >
> > public void setName(String name)
> > {
> > vo.setName(name);
> > }
> >
> > // and so on....
> >
> > // get the vo
> > public EmployeeVO getEmployeeVO()
> > {
> > return vo;
> > }
> > }
> >
> > so say you have an action class:
> >
> > public class AddEmployeeAction()
> > {
> > public void perform( ... )
> > {
> > EmployeeForm eform = (EmployeeForm) form;
> > employeeManager.add(eform.getEmployeeVO());
> > }
> > }
> >
> > etc... very simplified example, but hopefully this is a bit clearer... I
> > use this all the time, and would be interested to hear what other ppl
> > think as well...
> >
> > cheers
> > dim
> >
> > On Thu, 22 Nov 2001, Sobkowski, Andrej wrote:
> >
> > > Michelle,
> > >
> > > thanks for your reply... but I'm not sure I understand your answer.
>Probably
> > > my message wasn't clear.
> > >
> > > To use an example, I have:
> > >
> > > EmployeeForm extends ActionForm
> > > +getName():String
> > > +getAge():String
> > > +getDateOfBirth():String
> > >
> > > EmployeeVO
> > > +getName():String
> > > +getAge():Integer
> > > +getDateOfBirth():Date
> > >
> > > EmployeeForm is a simple Struts mapping of the data displayed on the
>HTML
> > > page. EmployeeVO is the intermediate value/business object where the
>fields
> > > have a "real" meaning (a Date is a Date).
> > >
> > > I don't see the reasons of making EmployeeVO an instance variable of
> > > EmployeeForm. And EmployeeVO can not be used directly inside Struts to
>map
> > > data from an HttpRequest because (I think) that only Strings (and
>int?)
>can
> > > be handled in ActionForms.
> > >
> > > My question was somehow: should I get rid of EmployeeVO? It certainly
>makes
> > > the application cleaner but it may just be a "picky thing" that will
>simply
> > > waste resources.
> > >
> > > Thanks.
> > >
> > > Andrej
> > > -----Original Message-----
> > > From: Michelle Popovits [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, November 22, 2001 4:13 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Design question - Action Form vs Business Delegates/Value
> > > Objects
> > >
> > >
> > > Hi,
> > >
> > > I suggest to not duplicate variables that are in your Value Objects in
>your
> > > form object. Instead include the value object as a member of the the
>form
> > > object.
> > >
> > > ie.
> > >
> > > Form class - below the AccountVo is a value object within the form
>bean
> > >
> > > public class AddAccountForm extends ActionForm {
> > > ....
> > >
> > > public AccountVo getAccount() {
> > > return account;
> > > }
> > >
> > > public void setAccount(AccountVo aAccount) {
> > > account = aAccount;
> > > }
> > >
> > > ....
> > > }
> > >
> > > Then, in your jsp you reference the accountvo members like so using
>the
>dot
> > > notation -- the property "account.password" gets converted to
> > > getAccount().getPassword() or getAccount().setPassword(value).
> > >
> > > <strutshtml:password property="account.password" size="30"
>maxlength="10" />
> > > <strutshtml:text property="account.accountName" testexpr="eMail"
>size="60"
> > > maxlength="100" />
> > >
> > >
> > > This feature of struts/javabeans is a real time saver in terms of
> > > development. Once something is in a value object then that value
>object
> > > gets passed from the back-end all the way to the front end without
>needing
> > > to touch any of it's attributes. And if you're editing the data on a
>web
> > > page when you submit the page the new data automatically gets set into
>the
> > > value object which can then be passed to the back end (no unnecessary
> > > handling of the data).
> > >
> > > HTH,
> > > Michelle
> > >
> > > >From: "Sobkowski, Andrej" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Users Mailing List"
><[EMAIL PROTECTED]>
> > > >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > >Subject: Design question - Action Form vs Business Delegates/Value
>Objects
> > > >Date: Thu, 22 Nov 2001 13:28:05 -0500
> > > >
> > > >Hello,
> > > >
> > > >we're working on a quite large project with J2EE (including EJBs) and
>we're
> > > >using Struts (we're still in the early phases). To design a "clean"
> > > >application, I've defined different "object conversions":
> > > >* Request phase
> > > >- the ActionForm is converted to a Value Object
> > > >- the Value Object is passed to the EJBs
> > > >* Response phase
> > > >- the EJBs return one ore more Value Objects
> > > >- the Value Object(s) is (are) converted back to ActionForms.
> > > >
> > > >I think it's a good approach, but:
> > > >- my ActionForm and Value Objects have an almost identical interface.
>The
> > > >main difference is that the ActionForm instance variables are always
>of
> > > >type
> > > >String while for the Value Object have "final types" information
>(Date,
> > > >Integer, whatever)
> > > >- the conversion "ActionForm to VO" and back is slowing down the
> > > >performance
> > > >as my EJBs often return hundreds of VOs (each one to be converted to
>an
> > > >ActionForm).
> > > >I know this can be improved by using paging (Page-by-Page iterator)
>on
>both
> > > >the back-end and the front-end; furthermore, I've written a small
>"mapper"
> > > >that uses extensively the Reflection API to automatically perform the
> > > >mapping and this probably has an impact on the overall performance.
> > > >
> > > >My question is: what are the best practices for this type of issues?
>Does
> > > >anybody have the same problems? Should I reduce the level of
>abstraction
> > > >between the layers?
> > > >
> > > >Thank you!
> > > >
> > > >Andrej
> > > >
> > > >PS. if you're interested, I can share the simple mapper. It's a very
>small
> > > >mapper (less than 15k) that works fine with my app. It's waaaaaaay
>less
> > > >complete than the mapper on Ted Husted's site but...
> > > >
> > > >-----Original Message-----
> > > >From: Jon.Ridgway [mailto:[EMAIL PROTECTED]]
> > > >Sent: Thursday, November 22, 2001 12:10 PM
> > > >To: 'Struts Users Mailing List'
> > > >Subject: RE: design question
> > > >
> > > >
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: M`ris Orbid`ns [mailto:[EMAIL PROTECTED]]
> > > >Sent: 22 November 2001 16:54
> > > >To: Struts-list (E-mail)
> > > >Subject: design question
> > > >
> > > >Hello
> > > >
> > > >I have several questions about design, "best practises":
> > > >
> > > >1) Where to store client's profile information (like login name) ?
> > > >session or system state bean ?
> > > >
> > > >Use the HttpSession. But be aware that you should put as little as
>possible
> > > >into the session. Large sessions do not work well in a cluster.
> > > >
> > > >2) How to create and use a system state bean ?
> > > >
> > > >System state bean should be in scope "session", shouldnt it ?
> > > >
> > > >Again put as little as possible in the session and avoid statefull
>session
> > > >beans. If you must put a bean in the session, make it as small as
>possible,
> > > >ideally it would just hold key info that can be used to request beans
>at
> > > >request level when needed. This is a trade off between performance
>and
> > > >scalability.
> > > >
> > > >3) Where to put business logic (where I invoke JDBC) ?
> > > > Should business logic class be a bean ?
> > > >
> > > >If you have an app server business logic should go into a stateless
>session
> > > >bean (BusinessService), which is invoked (via a BusinessDelegate)
>from
>a
> > > >struts Action class. If you are not using EJBs then the Action class
>should
> > > >still invoke a business delegate, but the delegate would simply
>create
>a
> > > >normal Java bean to act as the Business Service. The business service
> > > >(Stateless EJB or Java Bean) should delegate to another class to
>access
>a
> > > >datasource. If your are using EJBs this should be a CMP or BMP+DAO
> > > >depending
> > > >on your app server (EJB 2 compliant consider CMP, else try CMP if
>supported
> > > >but be prepared to subclass to a BMP+DAO at a later date).
> > > >
> > > >thanx in advance
> > > >Maris Orbidans
> > > >
> > > >
> > > >Jon Ridgway.
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> > > ><mailto:[EMAIL PROTECTED]>
> > > >For additional commands, e-mail:
> > > ><mailto:[EMAIL PROTECTED]>
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
>http://explorer.msn.com/intl.asp
> > >
> >
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
