> W/ a Map:
> - you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
> - It's dynamic, when DAO SQL string changes... so does your
> jxTable/Displaytag.
>
> I removed an entire layer and still have the layer.
>
> Developers are so pasionate... that's what makes them good.
I'm with you on this one. I see DTO's being misused in the Struts
world. The pattern originally solved the overhead associated with
invoking getters/setters over a network. In the world of web browser
sends/requests data from a single application server, where does the DTO
fit in? I don't see it.
That said, a form object is kind of like a DTO in that it serves as a
staging area for the users data and generally has a more fine grained
view of the data (not a 1 to 1 mapping with business domain objects).
Jumping right in, my Actions pass DynaBeans to a service layer. The
service layer processes the DynaBean. Here's an example from a service
interface:
public interface PersonnelService {
/**
* Stores an employee.
* <ul>
* <li>id - Long - required for update, null or 0 for create</li>
* <li>first - String</li>
* <li>middle - String (optional)</li>
* <li>last - String</li>
* <li>email - String</li>
* <li>phone - String (optional)</li>
* </ul>
* @param employeeBean the bean containing the employee properties
* @return the resultant employee
*/
public Employee storeEmployee(DynaBean employeeBean);
/**
* Gets the employee with the given id.
* @param id id of employee
* @return the employee
*/
public Employee findEmployeeById(long id);
}
Here's an Action that serves as a client for this service:
public class EmployeeAction extends BaseMappingAction {
public ActionForward save(ActionMapping mapping,
ActionForm form, HttpServletRequest
request,
HttpServletResponse response)
throws Exception {
DynaBean employeeBean = (DynaBean) form;
try {
service.storeEmployee(employeeBean);
} catch (...) {
// handle various errors
}
return mapping.findForward("personnel");
}
}
Here's a unit test that serves as a client for this service:
public void testAddEmployee() throws Exception {
DynaBean employeeBean = new LazyDynaBean();
employeeBean.set("first", "Sam");
employeeBean.set("middle", "G");
employeeBean.set("last", "Kroner");
employeeBean.set("email", "[EMAIL PROTECTED]");
employeeBean.set("phone", "(210) 555-7632");
Employee employee = service.storeEmployee(employeeBean);
...
}
Here's an abbreviated implementation of the PersonnelService
storeEmployee method:
public Employee storeEmployee(DynaBean employeeBean) {
Employee employee = new Employee();
// do the work of creating an Employee object based on the bean
...
employeeDAO.store(employee);
return employee;
}
I'm guessing that the coupling police will start screaming... Yes,
there is some documentation overhead in the PersonnelService interface,
but I don't want Actions doing any business logic. Actions simply pass
the data from client, put things in the various scopes, and direct to
the proper view.
The Map camp would probably say that no Employee class is needed at all,
putting me somewhere in between the Map camp and the Bean camp. I use
Hibernate, so beans are the best option on the backend. Apparently
iBatis works very well with maps.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
