对工作流程中跟踪数据进行版本控制的最佳方法是什么？
这是一个关于 Workflow Foundation (.NET 3.5) 及其所使用的数据版本控制的常见问题。我们有很多与某些数据一起使用的自定义活动，这些数据对于未来对已完成的工作流程的分析也可能很有趣（前提是我们以序列化形式存储它的方式配置跟踪）。
可能有必要在 UI 中显示过去的数据，但数据不可避免地会改变结构（类定义/内部结构，如果是动态的），并且我们库的重新部署版本将包含新的数据定义，而序列化数据在跟踪数据库仍将采用旧结构。
是使用从一开始就不变的动态结构（如属性包）更好，还是稍后处理重新部署并以某种方式将序列化的 BLOB 转换为新的 BLOB 更好？您是否曾在类似场景中使用过某种方法？
This is a general question concerning the Workflow Foundation (.NET 3.5) and versioning the data that it works with. We have a lot of custom activities that work with some data and this data may be interesting also for the future analysis of the already completed workflows (provided that we configure the tracking in such a way that it stores it in a serialized form).
It may be necessary to show the data from the past in the UI, but the data inevitably changes the structure (class definition / internal structure if it's dynamic) and the redeployed version of our library will contain the new data definition while the serialized data in the tracking database will be still in the old structure.
Is it better to use dynamic structures that don't change from the beginning (like a property bag) or rather later deal with the redeployment and somehow transform the serialized BLOB into the new one ? Have you ever used some approach in a similar scenario ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很大程度上取决于您如何部署应用程序。如果您使用强名称并部署到 GAC 或多个私有程序集路径，则反序列化工作流将反序列化类的确切版本。这意味着您的代码必须能够使用多个版本，这可能有点痛苦。将数据存储在属性包中不会对您有帮助。如果您使用程序集重定向来指向活动的当前版本，则可以解决该部分问题，我想使用属性包将使生活变得更简单。也就是说，到目前为止，我倾向于坚持使用依赖属性和常规可序列化类。
我写了一系列关于长期运行的工作流程和版本控制的博客文章，您会遇到完全相同的问题。请查看此处了解更多信息细节。
A lot depends on how you deploy your application. If you use a strong name and deploy to the GAC or multiple private assembly paths deserializing a workflow will deserialize the exact version of your class. That means that you code must be able to work with multiple versions and that can be a bit of a pain. Storing data in a property bag is not going to help you there. If you use assembly redirects to point to the current version of an activity solves that part and I suppose using a property bag would make life simpler then. That said I tend to stick with dependency properties and regular serializable classes so far.
I did a series of blog posts about long running workflows and versioning where you run into exactly the same problem. Check here for more details.