长话短说,我们有一个老化的应用程序,在我们开发它的这些年里,它变得有些笨拙。不过,有一些固定的东西已经开始引起问题,这让我开始思考如何更好地构建数据。但是,这样做的问题是,我们需要维护对客户可能拥有的旧序列化数据文件的支持,如果我们对类进行任何彻底的更改,这使得迁移到新版本变得非常困难。
我的问题是,如果我们决定投入一些精力来重构代码,是否有一个好的、经过测试的流程/架构模式可以在未来帮助我们?
编辑都是二进制序列化
长话短说,我们有一个老化的应用程序,在我们开发它的这些年里,它变得有些笨拙。不过,有一些固定的东西已经开始引起问题,这让我开始思考如何更好地构建数据。但是,这样做的问题是,我们需要维护对客户可能拥有的旧序列化数据文件的支持,如果我们对类进行任何彻底的更改,这使得迁移到新版本变得非常困难。
我的问题是,如果我们决定投入一些精力来重构代码,是否有一个好的、经过测试的流程/架构模式可以在未来帮助我们?
编辑都是二进制序列化
只是大声思考,但类似于 COM 过去“版本”事物的方式可能会起作用..类似于:
[Serializable]
public class Data
{
public string Field1 {get; set;}
}
[Serializable]
public class Data2
{
public Data2() { _version1 = new Data();}
[NonSerialized]
private Data _version1;
public string Field1
{
get { return _version1.Field1;}
set { _version1.Field1 = value;}
}
public int Field2 {get; set;}
}
[Serializable]
public class Data3
{
public Data3() { _version2 = new Data2();}
[NonSerialized]
private Data2 _version2;
public string Field1
{
get { return _version2.Field1;}
set { _version2.Field1 = value;}
}
public int Field2
{
get { return _version2.Field2;}
set { _version2.Field2 = value;}
}
public double Field3 {get; set;}
}
实际上,现在我正在看这个摆在我面前的东西,我不能说它接近理想的解决方案。它会很快导致“版本号地狱”的泛滥,这很像现在的 COM(有时查看各种 DirectX 接口名称)
也就是说,这是一个潜在的答案,所以我会留下它。