The reason Save() returns another instance is because the .NET
serialization process creates a clone of the object across the network. This is
discussed in Chapter 1. Because the object graph is cloned from client to app
server, and from app server to client, the client ends up with a different
object as a result.
When using the local data portal CSLA used to just modify the
existing object instance (no cloning). The problem there is a big one: if your
update fails part way through the process, the database will roll back and be
consistent. But the object graph will be very inconsistent. Some objects
will have new timestamps or new database-generated id values, etc. None of
which will be correct. So the object graph (in that case) is totally broken.
That meant that the UI developer had to write code to determine
if the data portal would be local or remote, and to work differently in those
two scenarios. It also meant that the UI developer had to clone the object
graph before saving when using a local data portal. Not doing that clone was a
bug.
So in CSLA 3.0 I added the option to have CSLA do the clone for
you (because too many people were forgetting, and that is a bug). And in 3.5 I
switched the default so CSLA defaults to doing the right thing, though you can use
the config setting to revert to the older, broken, behavior for backward
compatibility.
Rocky
Rocky