On 2/28/06, R.Vijayaraghavan <[EMAIL PROTECTED]> wrote:
> I am not using EJB. The model is made using simple JDBC that gets the
> database connection from a helper class which uses JNDI to get the JDBC data
> source.
>
> How can I apply Session Facade here. Is there any text or code examples
> which I can read that talks the same with relation to struts.
The most straight forward way would be to have a class with all your
JDBC in. If you don't want to write a bunch of domain objects/entities
then you could pass hashmaps to your action.
public class DatabaseService {
public Map findUserById(Long id) {
//get your jndi connection and populate a map from the resultset
}
}
in your action
DatabaseService service = new DatabaseService();
Map user = service.findUserById(id);
UserForm theForm = (UserForm) form;
BeanUtils.populate(theForm,user);
Of course using some properly typed objects for your model might be
preferable but Maps will do the job. Spring will give you a clear path
to achieving this, and better than my example, but this will give you
a way of defining your fasade and a path to unit testing your jdbc
code separate to your actions etc.
There are more optimisations you can do, and improvements to the
example I've given, but this is basically what folk are talking about.
Its also true that for your application it might be perfectly okay to
do jdbc stuff in your actions, this will make it less unit testable
and so on, but sometimes blue prints and patterns can be overkill.
Having your jdbc exceptions in your action allows you to pass messages
back to the view in a easy manner.
try {
//do some jdbc
} catch (SQLException e) {
ActionMessages messages = ..
saveErrors(...)..
}
The disadvantages of doing this however is the fact that unit testing
is harder and your actions get kinda long. But its not always the root
of all evil as some would have one believe.
Mark
>
> regards,
> vijay.
>
> > -----Original Message-----
> > From: Oshima Tlholoe [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 28, 2006 2:53 PM
> > To: Struts Users Mailing List
> > Subject: Re: which method is better
> >
> >
> > With my rudimentary knowledge,I dont think its advisable for your Action
> > classes to talk directly to your business layer/model classes,
> > Why don't you
> > have a business delegate/session facade or Service Locator sitting between
> > your Action Classes and the model classes, this insulates your action
> > classes from your business layer and it even makes testing
> > simpler. You not
> > going to have test cases that span multiple layers.
> > Let your Actions pull out data from the ActionForm, wrap it and pass it to
> > the Service Locator, then the Service Locator then handles the
> > rest, calling
> > all the related model classes.
> >
> >
> >
> > On 2/28/06, R.Vijayaraghavan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > I usually have set and get methods for all properties in my Model class.
> > > After submitting a form, I pull out all the property values
> > (form fields)
> > > in
> > > the Action class from the ActionForm object, set the values of all
> > > properties in the model from the action class and then call a particular
> > > method in the model class for final submission to the database.
> > >
> > > I wanted to know thether the above mentioned method is better or is it
> > > better to pass the form reference itself to the Model class which then
> > > sets
> > > the values.
> > >
> > > In situation 2, I do not have to take care of the various String
> > > references
> > > that I create. I simply will pass the ActionForm object to the Model
> > > class.
> > >
> > > regards,
> > > vijay.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Regards
> > Name : Oshima Tlholoe
> > Cell No: +2773 342 4393
> > Tel No : +2712 841 4355(w)
> > E-mail : [EMAIL PROTECTED]
> > simplicity is the ultimate sophistication
> >
>
>
>
> ---------------------------------------------------------------------
> 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]
