Should serialization logic be in the entity or other class

Question

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?

Answer 1

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.