Anyone in the mood to kick the dead horse again? I decided to compare two approaches to use/update data from Struts. I am obviously biased towards nested VO/BO, so maybe I left something out.
[I] Property copying This one seems to be the default and "officially endorsed" Struts practice. 1) Create/Load data. Workflow: * To use existing data it is loaded from database into BO/VO, then BO/VO properties are copied to action form. * To create new data nothing special is performed, action form is just cleaned if it has session scope. Notes: * BO/VO usually has strongly typed properties. * Validation is usually performed in the action form. * Intermediate data is flying around action form/request/response. * Because of double data copying (from database to BO/VO, then from BO/VO to action form) it is tempting to avoid BO/VO altogether or to make it as dumb as possible. Thus, this approach usually uses struct-type VO instead of behavioral BO. 2) Modify data Current data is kept in the action form, usually having request scope. Notes: * Request-scoped action forms do not allow to use two-phase request processing 3) Store data Workflow: * Data is validated in the action form first, then copied to BO/VO * BO/VO validates business rules * BO/VO is stored in the database Notes: * Business rules are validated after data is copied from action form to BO/VO; inefficient. * In this approach BO/VO is usually treated like a persistent object (EJB-style), that is modifications to BO/VO are immediately reflected in database. [II] Using nested BO/VO 1) Create/Load data. Workflow: * To use existing data it is loaded from database into BO/VO; this BO/VO is detached from database, that is all changes to it do not affect persistent data. * To enter new data a new instance of BO/VO is created; it is detached as well. ID/PK can be generated on this stage or is created on "store" stage. * BO/VO is kept in the session, or stored as nested object in the action form, which has session scope. Notes: * BO/VO usually has string properties or double-type properties: string/strong. Another choice is to define action form's setters as string, and to set BO data from within them. * Validation is performed partly by the BO/VO, and partly by the action form. * Intermediate data is kept in the BO/VO; transient data is kept in the action form. * This approach better supports OO model; enforces usage of a real BO with behavioral methods. 2) Modify data Current data is kept in the BO nested in the action form; action form has session scope. HTML form can either use/set nested properties directly, or use action form's setters/getters, which convert data and set it in the nested BO. 3) Store data Workflow: * Transient data is validated by the action form. * Business data is validated by nested BO * BO/VO is stored in the database Two major questions is where to perform validation and type conversion. One opinion is to perform validation and type conversion in an action form, and to have strongly typed VOs. Another is to have string- or string/strong properties for BO, which may provide better flexibility for different web frameworks and clients (for web service, WML, VoiceXML, non-Struts - most rules are in one place despite of different UI). Transient property may be stored in the BO to have all validation rules in BO. Did I miss something or got something wrong? Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
