10

Json.NET (シリアル化用) とGeoAPI.NET (ジオメトリ定義用 )を使用してオブジェクトをGeoJSONにシリアル化する C# ライブラリを作成しようとしています。

シリアライゼーションの実装について 2 つの異なるアプローチを考えましたが、どちらが最適なアプローチであるかはわかりません。彼らです:

アプローチ 1 - カスタム属性

最初のアプローチでは、シリアライゼーションを変更するために任意のクラスに適用できるいくつかのカスタム属性を作成します。たとえば、クラスは次のように装飾できます。

[GeoJsonFeature]
public class Building
{
   [GeoJsonId]
   public Guid Id { get; set; }
   [GeoJsonProperty]
   public string Name { get; set; }
   [GeoJsonProperty]
   public int Floorcount { get; set; }
   [GeoJsonGeometry]
   public GeoAPI.Geometries.IGeometry Geometry { get; set; }
}

オブジェクトのシリアル化は、次のように簡単になります。

JsonNetResult jsonNetResult = new JsonNetResult();
jsonNetResult.Formatting = Formatting.Indented;
jsonNetResult.Data = building;
return jsonNetResult;

このアプローチの利点は、必要なプロパティ ( Geometry など) があると仮定して、任意のビジネス オブジェクトを GeoJSON オブジェクトに変換できることです。欠点は、シリアル化をサポートするために多数のカスタム属性を作成する必要があることです。さらに、これはビジネス オブジェクトを「混乱させる」という影響があります。

最後に、このアプローチが JSON.NET でも可能かどうかはまだ判断していませんが、可能になるようです。

アプローチ 2 - カスタム JsonConverter

2 番目のアプローチでは、さまざまな型のカスタム コンバーターを作成します。たとえば、Feature などの特定のタイプのオブジェクトを渡すと、GeoJSON オブジェクトが作成される GeoJsonConverter があるとします。これは次のようになります。

public class GeoJsonFeatureConverter
{
    public override void WriteJson(JsonWriter writer, object value, JsonSerializer)
    {  
        // serializing code here 
    }

    public override void ReadJson(JsonReader reader, Type objectType, JsonSerializer serializer)
    {  
        // deserializing code here 
    }

    public override bool CanConvert(Type objectType)
    {
        return typeof(Feature).IsAssignableFrom(objectType);
    }
}

次に、次のように GeoJson にシリアル化できます。

JsonNetResult jsonNetResult = new JsonNetResult();
jsonNetResult.Formatting = Formatting.Indented;
jsonNetResult.SerializerSettings.Converters.Add(new GeoJsonFeatureConverter());
jsonNetResult.Data = building;

ここでの利点は、作成が簡単に見えることです。私は、このアプローチが非常に単純なプロトタイプによって可能であることを証明しました。さらに、NetTopologySuiteFeatureにリンクすると、クラスは既に定義されています。

Feature欠点は、シリアル化する前に、ビジネス オブジェクトを にマップする必要があることです。ただし、これはレイヤー間の自然な分離を提供する可能性があるため、利点と見なされる場合があります。どちらの場合も GeoAPI と密結合し、後者の場合は NetTopologySuite と密結合することは間違いありません。私はそれで大丈夫だと思います。

GeoJson.NETなど、他のいくつかの GeoJson シリアライザーが利用可能であることは承知していますが、これが選択したシリアライザーであるため、Json.NET API と一貫性のあるアプローチが必要です。

あるアプローチが他のアプローチよりも好まれる明確な理由はありますか? おそらく、私が気付いていない別のアプローチがありますか?

参考までに、私は2番目のアプローチに傾いています。実装が簡単になり、全体的にきれいになるようです。また、ドメイン オブジェクトとそれによって作成される GeoJson オブジェクトとの間の自然な境界も気に入っています。

4

1 に答える 1

2

個人的には、単純な理由から、最初の選択肢に傾倒します。.NET フレームワークを見ると、System.Xml.Serialization 名前空間にシリアル化に類似したものがあります。そこでは、最初のアプローチで提案していることをほぼ正確に実行します。

ただし、それが特に気に入らない場合は、3 番目の方法をお勧めします。System.Runtime.Serialization.IFormatter を実装して、カスタムのシリアル化フォーマッタを作成します。これにより、オブジェクトに標準のシリアル化表記法とメカニズム ([Serializable] や ISerializable など) を使用できるようになりますが、よく知られているパターンに従っているため、使用法を簡単に認識できます。さらに、追加のボーナスとして、IFormatter 実装を交換することで、他の形式のシリアル化 (バイナリ、soap、その他のカスタム形式) を簡単にサポートできます。

編集: ここに例があります: http://geekswithblogs.net/luskan/archive/2007/07/16/113956.aspx

于 2009-08-14T22:46:29.237 に答える