序列化逻辑应该在实体或其他类中 [英] Should serialization logic be in the entity or other class

问题描述

对象序列化逻辑（将字段映射到XML或JSON名称和值）应放在哪里？在每个实体对象中进入一个不同的类的集合只关心序列化？与这个问题有关的任何其他最佳做法？

例如：

  class Person {
 String name; 
} 
  

有些人这样说：

  class Person {
 String name; 
 public String toJson（）{
 //构建JSON，使用'name'字段
} 
} 
  

但是，如果我们还需要使用XML（），toCSV（），toXYZ（）来保持该方向将创建可怕的污染代码，并打破已经破坏的单一责任原则，即使使用单独的toJson方法，IMHO。

另一个选项，这是我通常做的：

 code> interface Serializer {public String toJson（）; } 
 
 class PersonJsonSerializer实现Serializer {
 private Person p; 
 public PersonJsonSerializer（Person p）{this.person = p; } 
 public String toJson（）{
 //构建JSON，使用p.name 
} 
} 
  

然后一个工厂根据实体类型输出Serializers：

  class JsonSerializerFactory {
 public Serializer getSerializer（Object o）{
 if（o instanceof Person）{
 return new PersonJsonSerializer（（Person）o）; 
} 
 else if（o instanceof Account）{
 return new AccountJsonSerializer（（Account）o）; 
} 
 // ... etc 
} 
} 
  

还有XMLSerializerFactory，CSVSerializerFactory等等。

然而，大多数人们希望完全控制序列化，不会购买进入它，并喜欢在每个类中都有toJson方法。他们会声称是更简单，更容易出错的问题。

有什么优先选择的方式，而且有更好的替代方案可以解决这个问题吗？ >

解决方案

我会说序列化逻辑不应该是POCO /数据类的一部分，原因很多：

1. 单一责任原则（数据类只能定义数据模型，注释序列化逻辑）


2. 可能有不同种类的序列化器可能需要（json / xml等等，如您所提到的）


3. 大多数时间的序列化实现是通用解决方案或外部包。即使你想要一些对象的自定义实现，仍然可以有一个通用的解决方案，你可以扩展到特定的类，所以不需要为每个类。


4. 你可以装饰你的具有属性的POCO类，用于指定特殊条件的序列化（例如控制属性，属性名称甚至客户序列化程序的复杂类型属性的序列）

还有其他原因，但有一些强有力的论据，为什么不应该将序列化逻辑放入您的POCO /数据模型中。

Where should object serialization logic (the mapping of fields into XML or JSON names and values) be placed? Inside each entity object OR into a different set of classes only concerned with serialization? Any other best practices out there that relate to this question?

For example:

class Person {
    String name;
}

Some people go about it this way:

class Person {
    String name;
    public String toJson () {
      // build JSON, use 'name' field
    }
}

But if we also needed toXML(), toCSV(), toXYZ() keeping that direction would create horribly polluted code and break the Single Responsibility Principle which is already broken even with a single toJson method, IMHO.

Another option and this is what I typically do:

interface Serializer {  public String toJson (); }

class PersonJsonSerializer implements Serializer {
    private Person p;
    public PersonJsonSerializer (Person p) { this.person = p; }
    public String toJson () {
      // build JSON, use p.name
    }
}

then a factory hands out Serializers depending on entity types:

class JsonSerializerFactory {
    public Serializer getSerializer (Object o) {
        if (o instanceof Person) {
            return new PersonJsonSerializer ((Person)o);
        }
        else if (o instanceof Account) {
            return new AccountJsonSerializer ((Account)o);
        }
        // ... etc
    }
}

There would also be XMLSerializerFactory, CSVSerializerFactory, and so forth.

However, most of the times people want to have full control over the serialization and would not buy into it and prefer to have toJson methods inside each class. They would claim is way simpler and less error prone.

What is the preferred way to go, and are there better alternatives to implement a solution to this problem?

解决方案

I would say the serialization logic should not be part of the POCO/data classes for many reasons:

1. Single Responsibility Principle (data classes should only define data model, note serialization logic)
2. There could be different kinds of serializers that you may require (json/xml etc. as you mentioned)
3. Serialization implementation most of the time is a generic solution or an external package. Even if you want custom implementation for some objects, still you can have a generic solution which you can extend for specific classes, so no need to have it for each class.
4. You can decorate your POCO classes with attributes to direct the serializer for special conditions (like to control sequence of properties, property names or even a customer serializer for complex type properties)

There will be other reasons as well but there are some strong arguments why you should not put the serialization logic into your POCO/Data Model.

这篇关于序列化逻辑应该在实体或其他类中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！