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