Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for in-place deserialization of an object graph #712
Enhance the data portal so the result of an Update operation can optionally be merged back into the existing client-side object graph.
To do this, every object in the graph must be assigned a unique (to the graph) id value (probably an int) so the identity of the object can be tracked as the data portal request flows to the server and then back to the client. This will allow the graph that comes back from the server to be merged into the existing client-side graph because the identities of all objects will be known.
Add Identity property to IBusinessObject so all objects will now carry a unique identifier (within the scope of the object graph). Also add code to IParent to generate unique identity values within an object graph. Still need to wire up calls to GetNextIdentity as objects are created or added to the graph. Still need to traverse the graph on deserialization to set the _nextIdentity value - or add that value to the serialization stream, but I think it will be best to recalculate it.
Closes #712 - adding a `GraphMerger` class that understands how to merge the results of a `Save` or `SaveAsync` method call back into the existing object graph. For example: ```c# var result = obj.Save(); var m = new Csla.Core.GraphMerger(); m.MergeGraph(obj, result); ``` To make this happen a number of changes have been made to CSLA: * Every `IBusinessObject` type (all stereotypes) now implement an `Identity` property; for all editable stereotypes this value is an `int` that is unique within the object graph * The `GraphMerger` class implements code to merge one graph into another, working against `BusinessBase` and `BusinessListBase` types and object graphs composed of those two types. No other base classes are currently supported * Only managed properties are currently supported, not properties with private backing fields * Object metastate is managed such that the new/old/dirty status of the source object is reflected by the target object when the merge is finalized * Once an object's merge is complete, that object's business rules are executed with the assumption that the object's data has changed so the rules need to be rerun * Changed events are raised for each merged object, which should trigger data binding to refresh the UI bindings against that object (for smart client UI technologies)