Ich werde versuchen, eine C# -Bibliothek zu erstellen, um Objekte zu GeoJSON mit Json.NET (für die Serialisierung) und GeoAPI.NET (für Geometriedefinitionen) zu serialisieren.Vorschläge zum Erstellen eines benutzerdefinierten GeoJson-Serialisierers mit JSON.NET?
Ich habe über zwei verschiedene Ansätze für die Serialisierungsimplementierung nachgedacht und mir ist nicht klar, welches wäre der beste Ansatz. Sie sind:
Ansatz 1 - Benutzerdefinierte Attribute
Der erste Ansatz umfasst mehrere benutzerdefinierte Attribute erstellen, die auf jede Klasse angewendet werden, um die Serialisierung zu ändern. Zum Beispiel könnte eine Klasse wie so eingerichtet werden:
[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; }
}
Serialisierung das Objekt würde dann so einfach sein wie:
JsonNetResult jsonNetResult = new JsonNetResult();
jsonNetResult.Formatting = Formatting.Indented;
jsonNetResult.Data = building;
return jsonNetResult;
Der Vorteil dieses Ansatzes besteht darin, dass jedes Business-Objekt in eine umgewandelt werden konnte GeoJSON-Objekt unter der Annahme, dass es die erforderlichen Eigenschaften (z. B. Geometrie) aufweist. Der Nachteil wäre, dass ich eine Reihe von benutzerdefinierten Attributen erstellen müsste, um die Serialisierung zu unterstützen. Darüber hinaus hat dies den Effekt, dass das Geschäftsobjekt matschig wird.
Schließlich habe ich noch nicht bestimmt, ob dieser Ansatz sogar mit JSON.NET möglich ist, obwohl es so aussieht.
Ansatz 2 - Individueller JsonConverter
Der zweite Ansatz beinhaltet unterschiedliche individuelle Wandler zu schaffen. Zum Beispiel könnte ich einen GeoJsonConverter haben, der, wenn er ein Objekt eines bestimmten Typs, zB Feature, übergeben wird, das GeoJSON-Objekt erzeugt. Dies könnte wie folgt aussehen:
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);
}
}
ich dann wie so zu GeoJSON serialisiert wäre in der Lage:
JsonNetResult jsonNetResult = new JsonNetResult();
jsonNetResult.Formatting = Formatting.Indented;
jsonNetResult.SerializerSettings.Converters.Add(new GeoJsonFeatureConverter());
jsonNetResult.Data = building;
Der Vorteil hierbei ist, dass dies scheint einfacher zu erstellen. Ich habe bewiesen, dass dieser Ansatz über einen sehr einfachen Prototyp möglich ist. Außerdem ist die Klasse Feature bereits definiert, wenn ich auf NetTopologySuite verlinke.
Der Nachteil wäre, dass meine Geschäftsobjekte vor der Serialisierung auf Feature gemappt werden müssten. Dies könnte jedoch als ein Vorteil angesehen werden, da dies eine natürliche Entkopplung zwischen den Schichten bereitstellen könnte. In beiden Fällen würde es definitiv eine enge Kopplung mit der GeoAPI geben und in der späteren NetTopologySuite. Ich denke, ich bin damit einverstanden.
Ich kenne mehrere andere GeoJson-Serialisierer wie GeoJson.NET jedoch möchte ich einen Ansatz, der mit der Json.NET-API konsistent ist, da dies unser Serializer der Wahl ist.
Sehen Sie irgendwelche offensichtlichen Gründe, warum ein Ansatz gegenüber dem anderen bevorzugt wird? Vielleicht gibt es einen anderen Ansatz, den ich nicht kenne?
FYI, ich bin auf den zweiten Ansatz gelehnt. Es scheint, dass es einfacher zu implementieren wäre und insgesamt sauberer wäre. Ich mag auch die natürliche Grenze zwischen Domänenobjekten und GeoJson-Objekten, die sie erzeugen würde.