抽象类的序列化

Question

我正在尝试序列化，但遇到了抽象类的问题。

我在 Google 上搜索答案，找到了此博客文章 。 我试过了，而且有效。

好的，非常好。但请查看该项目的评论：

这个方法论似乎是隐藏的 真正的问题是 OO设计的不准确实现 模式，即工厂模式。

必须将基类更改为 引用任何新工厂类是 弄巧成拙。

稍微思考一下，代码 可以更改为任何派生的地方 类型可以与 抽象类（通过奇迹 接口）并且没有 XmlIninclude 是 必填。

我建议进一步研究 工厂模式似乎是 你想在这里实现什么。

评论者在说什么？他有点模糊。有人可以更详细地解释一下（举例）吗？还是他只是在胡说八道？

更新（阅读第一个答案后）

评论者为什么谈论

工厂模式

和

代码可以更改为任意位置 派生类型可以与 抽象类（通过 界面奇迹）

？

他想做一个这样的界面吗？

public interface IWorkaround
{
    void Method();
}

public class SomeBase : IWorkaround
{
    public void Method()
    {
        // some logic here
    }
}

public class SomeConcrete : SomeBase, IWorkaround
{
    public new void Method()
    {
        base.Method();
    }
}

Answer 1

他既是对的，又是错的。

对于像 BinaryFormatter 这样的东西，这不是问题；序列化流包含完整类型元数据，因此如果您有：

[Serializable] abstract class SomeBase {}
[Serializable] class SomeConcrete : SomeBase {}
...
SomeBase obj = new SomeConcrete();

并序列化 obj，那么它会在流中包含“I'm a SomeConcrete”。这使生活变得简单，但也很冗长，尤其是在重复时。它也很脆弱，因为它在反序列化时需要相同的实现；对于不同的客户端/服务器实现或长期存储来说都是不利的。

对于 XmlSerializer（我猜博客正在谈论它），没有元数据 - 但元素名称（或 xsi:type 属性）用于帮助识别哪些元数据被使用。为此，序列化器需要提前知道哪些名称映射到哪些类型。

最简单的方法是用我们知道的子类来装饰基类。然后，序列化程序可以检查其中的每一个（以及任何其他特定于 xml 的属性），以确定当它看到 元素时，该元素映射到 SomeConcrete实例（请注意，名称不需要匹配，因此不能仅按名称查找）。

[XmlInclude(typeof(SomeConcrete))]
public abstract class SomeBase {}
public class SomeConcrete : SomeBase {}
...
SomeBase obj = new SomeConcrete();
XmlSerializer ser = new XmlSerializer(typeof(SomeBase));
ser.Serialize(Console.Out, obj);

然而，如果他是一个纯粹主义者（或者数据不可用），那么还有一个替代方案；您可以通过 XmlSerializer 的重载构造函数单独指定所有这些数据。例如，您可以从配置（或者可能是 IoC 容器）中查找一组已知子类型，并手动设置构造函数。这并不是很棘手，但它已经足够棘手了，除非您真正需要它，否则不值得这样做。

public abstract class SomeBase { } // no [XmlInclude]
public class SomeConcrete : SomeBase { }
...
SomeBase obj = new SomeConcrete();
Type[] extras = {typeof(SomeConcrete)}; // from config
XmlSerializer ser = new XmlSerializer(typeof(SomeBase), extras);
ser.Serialize(Console.Out, obj);

此外，对于 XmlSerializer，如果您采用自定义构造器路线，则缓存和重用 XmlSerializer 实例非常重要；否则，每次使用都会加载一个新的动态程序集 - 非常昂贵（它们无法卸载）。如果您使用简单的构造函数，它会缓存并重用模型，因此仅使用单个模型。

YAGNI 规定我们应该选择最简单的选项；使用 [XmlInclude] 无需使用复杂的构造函数，也无需担心缓存序列化程序。不过，还有另一个选项并且得到完全支持。

---

关于您的后续问题：

通过“工厂模式”，他谈论的是您的代码不知道SomeConcrete的情况，可能是由于IoC/DI或类似的原因框架；所以你可能会：

SomeBase obj = MyFactory.Create(typeof(SomeBase), someArgsMaybe);

找出适当的 SomeBase 具体实现，实例化它并将其返回。显然，如果我们的代码不知道具体类型（因为它们仅在配置文件中指定），那么我们就不能使用 XmlInclude；但我们可以解析配置数据并使用ctor方法（如上所述）。实际上，大多数时候 XmlSerializer 与 POCO/DTO 实体一起使用，因此这是一个人为的担忧。

并重新接口；相同的事情，但更灵活（接口不需要类型层次结构）。但 XmlSerializer 不支持此模型。坦白说，很难；那不是它的工作。它的工作是允许您存储和传输数据。不执行。任何 xml 模式生成的实体都不会具有方法。数据是具体的，而不是抽象的。只要你想到“DTO”，接口争论就不是问题。因无法在其边界上使用接口而烦恼的人们还没有接受关注点分离，即他们正在尝试做：

Client runtime entities <---transport---> Server runtime entities

而不是限制较少的

Client runtime entities <---> Client DTO <--- transport--->
           Server DTO <---> Server runtime entities

现在，在许多（大多数？）情况下，DTO 和实体 可以相同；但如果你试图做一些传输不喜欢的事情，请引入 DTO；不要对抗序列化器。当人们努力编写他们的对象时，同样的逻辑也适用：

class Person {
    public string AddressLine1 {get;set;}
    public string AddressLine2 {get;set;}
}

作为表单的 xml：

<person>
    <address line1="..." line2="..."/>
</person>

如果你想要这个，引入一个与传输相对应的 DTO，并在你的实体和 DTO 之间进行映射：

// (in a different namespace for the DTO stuff)
[XmlType("person"), XmlRoot("person")]
public class Person {
    [XmlElement("address")]
    public Address Address {get;set;}
}
public class Address {
    [XmlAttribute("line1")] public string Line1 {get;set;}
    [XmlAttribute("line2")] public string Line2 {get;set;}
}

这也适用于所有其他问题比如：

• 为什么我需要一个无参数构造函数？
• 为什么我的集合属性需要一个设置器？
• 为什么我不能使用不可变类型？
• 为什么我的类型必须是公开的？
• 如何处理复杂的版本控制？
• 如何处理具有不同数据布局的不同客户端？
• 为什么我不能使用接口？
• 等等

你并不总是遇到这些问题；但如果你这样做了——引入一个（或多个）DTO，你的问题就会消失。回到关于接口的问题； DTO 类型可能不是基于接口的，但您的运行时/业务类型可以是。

Answer 2

**Example of Enum Abstract Serializer

Simple example of an abstract enum ...(Java)(Spring-Boot) 
----------------------------------------------------------------------------------**


@JsonSerialize(using = CatAbstractSerializer.class)
public enum CatTest implements Tes{

    TYPE1(1, "Type 1"), TYPE2(2, "Type 2");

    private int id;
    private String nome;

    private CatTest(int id, String nome) {
        // TODO Auto-generated constructor stub

        this.id = id;
        this.nome = nome;


    }
    @JsonValue
    public int getId() {
        return id;
    }
    @JsonSetter
    public void setId(int id) {
        this.id = id;
    }
    @JsonValue
    public String getNome() {
        return nome;
    }
    @JsonSetter
    public void setNome(String nome) {
        this.nome = nome;
    }
    @Override
     @JsonValue
     public String toString() {
            return nome;
     }
     @JsonCreator
        public static CatTest fromValueString(String nome) {
            if(nome == null) {
                throw new IllegalArgumentException();
            }
            for(CatTest nomeSalvo : values()) {
                if(nome.equals(nomeSalvo.getNome())) {
                    return nomeSalvo;
                }
            }
            throw new IllegalArgumentException();
        }


}


public interface Tes {

    @JsonValue
    int getId();

    @JsonValue
    String getNome();

    @JsonSetter
    void setId(int id);

    @JsonSetter
    void setNome(String nome);


}

public class CatAbstractSerializer<T extends Tes> extends JsonSerializer<T> {

    @Override
    public void serialize(T value, JsonGenerator gen, SerializerProvider serializers)
            throws IOException, JsonProcessingException {
        // TODO Auto-generated method stub

        gen.writeStartObject();
        gen.writeFieldName("id");
        gen.writeNumber(value.getId());
        gen.writeFieldName("name");
        gen.writeString(value.getNome());
        gen.writeEndObject();

    }

}