Since CSLA moved toward auto-cloning and saving of the clone object while leaving the original untouched, I'm trying to find the best way to handle the special case where an object appears "valid" before being sent over the data portal, and then server-side rules are run and the object is broken on the server.
Throwing an exception is apparently useless, because when you do this the broken object isn't returned to the client.
For now, I've implemented this via a CommandBase derived class that will ferry the BO over to the server, attempt to save it, and return both the broken BO and result of the save operation. It catches any exception thrown server side, rolls back the transaction, and returns the broken BO, indication of success/failure, and the exception itself, if serializable. This is exposed from our base BO class as an instance method:
public bool Save(out T resultBO, out Exception e)...
How are others handling this type of requirement?
When you throw an exception on the server, the object is returned to the client through the DataPortalException.
The object graph, as it was when the exception occurred, is returned as a property of the exception so it is available to client-side code (most notably your factory method or Save() override).
How did I miss that? That's perfect, as long as any exception thrown server-side during a normal Create/Update/Delete type operation ends up wrapped in a DataPortalException.
Thanks for straightening me out..
Copyright (c) Marimer LLC