Best Practices Question: Issues that are not addr by Spring

[garpinc2]

I am trying to define a number of best practices where I have found no documentation or examples with Spring. I appreciate any feedback..


Standard Screen Submission Procedure
1) Determine attempted operation(s)
THE PROBLEM:
A particular event can result in multiple operations. For instance:
a) a "Save" button press could result in an insert of the parent and an insert into a collection of a new childen.
b) an "Update" button press could result in a update of the parent and and insert into a colection of it's children and if the child already exist in the collection it could instead be an update of the child
c) An "Add Additional" button press on an insert screen could result in an insert of the parent and an insert into a collection of a new child: i.e same as (1)
d) An "Add Additional" button press on an update screen could result in an update of the parent and an insert into a collection of a new child and if the child already exists in the collection it could instead be an update of the child

So How do you group the operations????
saveParent, saveChild, saveParentAddSubToCollection, saveParentRemoveSubFromCollection, saveParentUpdateSubInCollection, saveParentInsertOrUpdateSubInCollection?????

2) Populate required domain objects from view necessary to accomplish operation
THE PROBLEM
a) Which info is relavent to which operation
b) whats the best mapping framework to accomplish this
c) are DTOs necessary or should you user the domain object graph directly
3) Call service level procedure to accomplish operation
THE PROBLEM
a) Procedure for calling a transactional facade that performs each of the multiple operations within the scope of a transaction
b) Do you put the decision logic of which operation to perform in the service layer in which case you pass in all the data the service layer will decide what to do.
c) If the controller makes the decision then will there be a corresponding service layer method for every combination of operations that might occur
4) report successful operation(s)
THE PROBLEM
a) We will need a mechanism for exchange the successful statuses between the service layer and the controller
5) If failure report what failed and why
THE PROBLEM
a) We will need a mechanism for translating application exceptions into user readable exceptions
b) If there are multiple error status we will need a mechanism for exchanging the error statuses between the service layer and the controller

Standard Service Procedure
1) Call desired DAO to persist data
2) Alternate Flows based on persistent data
THE PROBLEM
a) since the database writes are flushed all together in the context of a transaction facade how do you perform operations based on the success or failure of the DB operation. i.e: I might want to do an insert and if the insert failed because of a duplicate key violation I might want to do an update.
b) If I force a flush in the service layer to implement this then I am circumventing the automatic flush provided by the transaction facade
2) throw application exceptions on failure (maybe there is a need to throw multiple exceptions or warnings)
THE PROBLEM
a) How do you ( or should you ) raise multiple exceptions at the same time
3) report different types of success and maybe multiple successes
THE PROBLEM
a) What mechanism will be used for transferring multiple sucess or error statuses back to the controller

[garpinc2]

Any ideas???