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]
