Yep. Lately, I've started writing inner classes to access the business logic for a particular transaction script. The inner classes take input in a way conventient to the client, (say, by passing in an ActionForm,) use that input to interact with the business classes, and return the output in a way convenient to the client.
I make these helpers throw-away inner classes so that they can stay very focused on a particular transaction script. Making them inner classes eliminates the temptation to try and share them, creating yet-another-layer. Inner clases also help reduce file-management bloat. It boils down to [Commands -- Business Rules and Persistence Logic] | [Business-Controller (CoR Catalog)] | [Helper (inner class)] | [Action/Code-Behind/Backing-Bean] The Helpers know which Transaction Scripts to call (IDs in the Catalog), but all the event handlers (Actions, Code-Behind, Backing Bean) know to do is call the Helpers. The Command is where the rubber meets the road. Here I make direct calls to iBATIS or JDBC or ADO or LDAP or Hibernate, or whatever. Since I can always replace a Command implementation if any of these details change, I don't worry about having another layer of abstraction. At first, I had the Commands calling gizmos like the iBATIS DAO, but there didn't seem to be any point. The Catalog is already a logical abstraction, so I cut to the chase, and now let the Commands call iBATIS and such directly. Of course, the Helpers are an example of the Facade pattern. -Ted. On Fri, 11 Mar 2005 05:58:40 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > Yes. > > You are describing almost exactly how I write my struts code. > > Here are the components I would use to maintain a Customer table: > - com.myorg.domain.bean.Customer.java > - com.myorg.domain.dao.CustomerDao.java (interface) > - com.myorg.domain.service.CustomerService.java (interface) > - com.myorg.domain.dao.ibatis.mapping.Customer.xml (sql map) > - com.myorg.domain.dao.ibatis.CustomerDaoImpl.java (DAO implementation) > - com.myorg.domain.service.impl.CustomerServiceImpl.java (service > implementation) > - com.myorg.domain.web.customer.CustomerAction.java (DispatchAction) > - com.myorg.domain.web.customer.CustomerForm.java (includes nested bean) > > I would then have 2 jsps (list.jsp and edit.jsp) that are in the > WEB-INF/jsp/customer/ directory. > > I make the interfaces between the service and dao layer to simplify > testing. It is super easy to write a faux dao impl for testing your > service class, and equally easy to write one for the service interface > when testing the action. > > Larry > > On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian > <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Struts DB Access Best Practices thread gave me great insight on how > > I should proceed with db operations. > > > > I have one more question. Where do you keep your business logic > > code. Right now I am thinking to use > > > > 1. Struts(JSP, Actions) > > 2. Simple class(Managers) to keep all our business logic code > > 3. IBATIS for database abstraction. > > > > Actions can call Managers to get the job done and Manager can use > > iBATIS to access DB. > > > > Is this a good approach or is there a better approach than this? > > > > Looking forward for your response. > > > > Have a great day. > > > > Karthikeyan B > > > > --------------------------------------------------------------------- > > 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] > > -- HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
