You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Je...@nlgroup.ca on 2002/09/05 18:08:37 UTC
[Architecture] Use of business delegate and Actions..
Greetings:
I would like to get an opinion on the preferred placement of code
between Actions and Business delegate methods.
Chucks book suggests that you might want to use a business interface for
your session facade and a client specific interface for the Business
Delegate
object. I like this idea. This may lead to business delegate object for
each type of client because each type may have special needs.
Most literature suggests that the business delegate method signatures are
the same as that of the session facade.
I would like to create a business delegate interface where the methods may
not resemble the business API much at all.
In our case we use a business delegate but still find ourselves performing
several operations on the business methods in our Actions.
We have no control over the business API so a common interaction in our
action is:
//get the delegate.
businessService = getBusinessService();
//get a list...
if(fullList){
userListWrapper = businessService.getUserList();
userList = userListWrapper.getFullList();
sortList(userList, sortOrder, sortColumn);
}else{
userListWrapper = businessService.getUserList();
userList = userListWrapper.getShortList();
sortList(userList, sortOrder, sortColumn);
}
All this just to get a list...
I feel that this could be replaced by a business delegate method:
userList = businessService.getUserList(fullList,sortOrder,sortColumn);
Should the business delegate operate on the business API or should it be a
pure proxy?
The reason I ask is that I have read that some people have created static
wrappers that do this kinda thing.
Any opinions would be welcome
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Architecture] Use of business delegate and Actions..
Posted by "Peter A. J. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
Robert Taylor wrote:
> An approach we have taken is to have a very course grained business service
> which encapsulates all business logic to support a set of common business
> requirements; so our Action class is really just a pure proxy to the
> business tier and the business service can be a proxy to the actual business
> components which may execute the logic. We also leverage DynaBeans so we can
> easliy transfer user I/O to our business service without coupling it to a
> specific presentation framework. Theoretically this allows us to reuse the
> business services with other presentation frameworks.
>
And another approach is to reduce the amount of business code in the
Struts Action and see if you could not place it on the business tier
layer ( EJB / JDO ). You could use ``SessionFacade'' on the business tier,
to reduce the number of network calls (RMI) to just one or two.
--
Peter Pilgrim +-----\ +-++----++----+
Java Technologist | | | || || | 'n' Shine
| O | | || --+| ---+
/\ | ._ / | | \ \ | |
/ \ | | \ \ | |+-- || ---+ A new day
/_ _\ "Up" | | | | | || || | is coming
|| +-+ +-+ +-++----++----+
<home page="http://www.xenonsoft.demon.co.uk/" />
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Architecture] Use of business delegate and Actions..
Posted by Ted Husted <hu...@apache.org>.
This is the kind of pattern I use myself. I've even taken it a step
further by refactoring the
IService service = getService();
service.doSomething(io);
part into a standard Action that you can configure from the Struts
config. It's a merger of the "ActionForm Instance" pattern and the
"DispatchAction" patterns. You can specify something like
parameter="my.serviceType;doSomething"
in the Struts config. Then the Action takes care of instantiating
"myServiceType" and calling doSomething.
Mine's tweaked out for the business service beans I use (ProcessBeans),
but the source could be adapted to any similar service.
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/
See ProcessDispatchAction.
I think this all stems back to the Workflow pattern Craig proposed last
year. We should be able to use a standard base Action to launch our
business service and be able to specify the service (or a complete
business service workflow) from a configuration file.
This way the Java engineers can focus on create flexible business
classes that work well together and turn the workflow into a set of
configuration details.
-Ted.
Robert Taylor wrote:
> An approach we have taken is to have a very course grained business service
> which encapsulates all business logic to support a set of common business
> requirements; so our Action class is really just a pure proxy to the
> business tier and the business service can be a proxy to the actual business
> components which may execute the logic. We also leverage DynaBeans so we can
> easliy transfer user I/O to our business service without coupling it to a
> specific presentation framework. Theoretically this allows us to reuse the
> business services with other presentation frameworks.
>
> So we end up with code like the following in our XXXXAction class. Notice
> that there is no business logic in the Action class operation:
>
> DynaBean io = (DynaBean) form;
>
> try {
>
> IService service = getService();
>
> service.doSomething(io);
>
>
> } catch(SomeException se) {
>
> // react to SomeException
>
> } catch(AnotherException ae) {
>
> // react to AnotherException
>
> }
>
>
>
> and in our IService.doSomething() implementation we have something like.
>
> void doSomething(DynaBean io) throws ServiceException {
>
> // extract data from io
>
> // convert into appropriate DTO (data transport object)
>
> // pass DTOs to business components to execute business logic
>
> // update io with results
>
> }
>
>
> So, in short, I think your on the right track with gut feeling.
>
> robert
--
Ted Husted, Husted dot Com, Fairport NY US
co-author, Java Web Development with Struts
Order it today:
<http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Architecture] Use of business delegate and Actions..
Posted by Robert Taylor <rt...@mulework.com>.
An approach we have taken is to have a very course grained business service
which encapsulates all business logic to support a set of common business
requirements; so our Action class is really just a pure proxy to the
business tier and the business service can be a proxy to the actual business
components which may execute the logic. We also leverage DynaBeans so we can
easliy transfer user I/O to our business service without coupling it to a
specific presentation framework. Theoretically this allows us to reuse the
business services with other presentation frameworks.
So we end up with code like the following in our XXXXAction class. Notice
that there is no business logic in the Action class operation:
DynaBean io = (DynaBean) form;
try {
IService service = getService();
service.doSomething(io);
} catch(SomeException se) {
// react to SomeException
} catch(AnotherException ae) {
// react to AnotherException
}
and in our IService.doSomething() implementation we have something like.
void doSomething(DynaBean io) throws ServiceException {
// extract data from io
// convert into appropriate DTO (data transport object)
// pass DTOs to business components to execute business logic
// update io with results
}
So, in short, I think your on the right track with gut feeling.
robert
> -----Original Message-----
> From: Jeff_Mychasiw@nlgroup.ca [mailto:Jeff_Mychasiw@nlgroup.ca]
> Sent: Thursday, September 05, 2002 12:09 PM
> To: struts-user@jakarta.apache.org
> Subject: [Architecture] Use of business delegate and Actions..
>
>
> Greetings:
> I would like to get an opinion on the preferred placement of code
> between Actions and Business delegate methods.
>
> Chucks book suggests that you might want to use a business interface for
> your session facade and a client specific interface for the Business
> Delegate
> object. I like this idea. This may lead to business delegate object for
> each type of client because each type may have special needs.
> Most literature suggests that the business delegate method signatures are
> the same as that of the session facade.
>
> I would like to create a business delegate interface where the methods may
> not resemble the business API much at all.
> In our case we use a business delegate but still find ourselves performing
> several operations on the business methods in our Actions.
>
> We have no control over the business API so a common interaction in our
> action is:
>
> //get the delegate.
> businessService = getBusinessService();
>
> //get a list...
> if(fullList){
> userListWrapper = businessService.getUserList();
> userList = userListWrapper.getFullList();
> sortList(userList, sortOrder, sortColumn);
> }else{
> userListWrapper = businessService.getUserList();
> userList = userListWrapper.getShortList();
> sortList(userList, sortOrder, sortColumn);
> }
> All this just to get a list...
>
> I feel that this could be replaced by a business delegate method:
>
> userList = businessService.getUserList(fullList,sortOrder,sortColumn);
>
> Should the business delegate operate on the business API or should it be a
> pure proxy?
> The reason I ask is that I have read that some people have created static
> wrappers that do this kinda thing.
>
> Any opinions would be welcome
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>