シリアル化ロジックはエンティティまたは他のクラスにある必要があります

debugcn 投稿 Dev

ホセ・シフエンテス

オブジェクトのシリアル化ロジック（フィールドのXMLまたはJSONの名前と値へのマッピング）はどこに配置する必要がありますか？各エンティティオブジェクト内、またはシリアル化のみに関係する異なるクラスのセットに？この質問に関連する他のベストプラクティスはありますか？

例えば：

class Person {
    String name;
}

一部の人々はこのようにそれについて行きます：

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

しかし、toXML（）、toCSV（）、toXYZ（）もその方向を維持する必要がある場合、ひどく汚染されたコードが作成され、単一のtoJsonメソッドであるIMHOでもすでに破られている単一責任の原則が破られます。

別のオプションとこれは私が通常行うことです：

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
    }
}

次に、工場はエンティティタイプに応じてシリアライザーを配布します。

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メソッドを含めることを好みます。彼らは、はるかに単純でエラーが発生しにくいと主張するでしょう。

進むための好ましい方法は何ですか？この問題の解決策を実装するためのより良い代替手段はありますか？

Naeem

多くの理由から、シリアル化ロジックをPOCO /データクラスの一部にすべきではないと思います。

単一責任の原則（データクラスはデータモデルのみを定義する必要があり、シリアル化ロジックに注意してください）
あなたが必要とするかもしれない異なる種類のシリアライザーがあるかもしれません（あなたが言ったようにjson / xmlなど）
ほとんどの場合、シリアル化の実装は汎用ソリューションまたは外部パッケージです。一部のオブジェクトにカスタム実装が必要な場合でも、特定のクラスに拡張できる汎用ソリューションを使用できるため、クラスごとに実装する必要はありません。
POCOクラスを属性で装飾して、特殊な条件（プロパティのシーケンス、プロパティ名、または複合型プロパティのカスタマーシリアライザーを制御するなど）のシリアライザーを指示できます。

他の理由もありますが、シリアル化ロジックをPOCO /データモデルに配置すべきではないという強い議論がいくつかあります。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集2021-04-9

コメントを追加

サインイン

分類Dev

Related 関連記事

記事