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
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
