I'm a newbie to CSLA and don't understand why the Save method must return an instance to be used to update all references to the current saved instance. It seems to me that using reflection we could have a generic procedure to auto-update all the current instance fields using the returned instance from the server.
There may be fields which aren't exposed as properties, but still must be set. Also, and I think this is the main reason, it becomes non-trivial to handle child lists. How do you update them, figure out which ones to remove, which ones were added, etc.
Having a friend method in each business object class that receives an object of its type as parameter and get all the public and private fields of that class and its ancestors we can set any field value based on the object received as parameter. For child collections, those items marked for deletion we should remove and having a serializable key property of type GUID we can locate for any child object in the parameter object graph its corresponding object in the current saved object. Is there anything else I'm not seeing?
This question been asked several times on the forums, but more importantly Rocky has also laid it out in his books (both paper and electronic). Those would be your best resource.
- Scott
It is true that if I required (or implemented in the base classes) a unique Id value per object, and was willing to take the perf hit to copy all the data values (one more time than they are already copied), it would be possible to do everything in-place.
What would be even more efficient would be to entirely discard the use of Microsoft's serialization engines, and to write my own. I could probably adapt the one from the CSLA COM (VB6) framework into .NET.
And it is this last point that is the ultimate driver for my decision. When I wrote CSLA .NET in 1999-2001, I went down that road. Then it occurred to me that it was crazy to ignore the beautiful serialization engines Microsoft had created (and would create later). So I specifically chose to rest the framework on Microsoft's work rather than inventing my own serialization engine.
Now, 12 years later, I am seriously thinking about inventing my own serialization engine. Not to address the issue in this thread, but to address the bandwidth issues caused by the DCS and NDCS. Although Microsoft's serializatin engines are really nice, they are generic - dumb - unintelligent. They assume (and rightly so) that the sender and reciever don't know much or anything about each other.
But in the case of a CSLA app the sender and reciever are the same code. Literally the same types, the same shape, everything is the same. At least in theory I can avoid shipping all the metadata that gets included by the NDCS/MobileFormatter, because the metadata already exists on both sides of the wire.
On the other hand, I'm trying to write 3.2 books in the next 4-5 weeks (ha!), then I'll take a sabbatical for the summer, then I'll need to create version 4.3 to support any new stuff in Silverlight 5. And September is Microsoft's "next big developer conference", and I rather suspect that'll cause non-trivial amounts of work to ensure CSLA helps us all move to (what I assume will be called) Windows 8.
In other words, as much fun as writing a new serializer might be (in a super-geeky sort of way), it won't happen any time soon.
Additionally, and finally, and this is the really big thing: such a change would break every CSLA app in existance. Thousands of apps would break. That's a big thing to consider. Would it be good in the end? Maybe. But it surely isn't something to approach with a casual attitude.
Codelines, while what you're suggesting might be feasible, why would I want to write all the extra code and add a guid to every object (increasing the size on the wire), just to move from obj = obj.Save() to obj.Save().
I'm not really seeing how the benefits are going to outweight the cons..
I think the problem is how to know where the business object is being referenced to update all these references througout the application with the new instance. But I think this could be addressed using not the business object directly, but a proxy that could receive the notification event every time the object is saved and so updating the internal reference the proxy would mantain to the business object.
Now thinking about my last post above, there is another issue: if the business object subscribes any event of another object, changing instances would break that connection.
The solution to the problem post avove would be any event be raised and subscribed by the proxy.
Copyright (c) Marimer LLC