When you have a long-running workflow that requires persistence, it seems like the only solution is to have the workflow framework serialize that workflow AND the business objects before storing them.
Wouldn’t this result in multiple copies of a given business object that could grow out of sync?
How do you handle the synchronization issues and why would you want to serialize the business object with the workflow (vs. maintaining a link between the workflow and the business object)?
I found a related question but it doesn’t really answer how to handle it or why you would want to do this.
Yes. Serialization allows the data to be persisted indefinitely in a single self-contained structure.
If code was designed with assumption that side-effects will somehow magically propagate, then yes. So don’t do that 🙂
This depends.
For instance, in a SharePoint environment, one may only keep the List Guid and Item Id (these are serialized with the Workflow) and then retrieve the Item on demand. That is, the SharePoint list Item serves as the “business object” which has a life(time) outside the Workflow. Because the Item is a shared external resource then, barring fun little race conditions, it is “in sync”.
When to not have “a link”? Well, when no such synchronization is required — e.g. the initial values are valid for the duration of the Workflow and/or immutable. Both methods can be employed together in a hybrid and it really depends upon the business logic requirements.
Happy coding.