Question

长期以来，我们有一个老化的应用程序，多年来我们一直在开发它。虽然已经开始引起一些问题，但是它让我思考如何更好地构建数据。但问题是，我们 NEED 维持对客户可能拥有的较旧的序列化数据文件的支持，如果我们对其进行任何彻底的更改，则很难迁移到新的版本我们的课程。

我的问题是，如果我们决定投入一些精力来重构代码，是否有一个良好的，经过测试的流程/架构模式可能会对我们未来有所帮助？

编辑这是所有二进制序列化

Answer 1

只是大声思考，但类似于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接口名称）

那就是说，是一个潜在的答案，所以我会离开它。

当我们需要维护传统支持时，如何更新现有数据结构？

1 个答案: