Oft stoßen wir auf Code, bei dem wir das JSON-Format ohne eigentliche Datenvertragsprüfung verwenden. z.B. Ich habe einen ASP.Net serverseitigen Code, der eine serialisierte Antwort an Javascript-Client zurückgibt. Außerdem verwendet dieser Client einige der Werte innerhalb der Antwort, um andere serverseitige Aufrufe durchzuführen. Obwohl nicht sehr häufig, aber wir sehen Probleme, bei denen jemand den Dateityp auf der Serverseite erhöht hat und die Client-Seite in einer wirklich schlechten Art und Weise zerstört hat. Ich bin auf der Suche nach Vorschlägen, wie kann ich ein korrektes Build-Time-Validierungssystem implementieren, um solche Probleme zu vermeidenJSON zu Javascript Serialisierungs-/Deserialisierungsvalidierung
Lassen Sie mich mit einem hypothetischen Beispiel erklären. Der Client ruft getCars(int employeeID) ==> Antwortobjekt hat List<CarIDs, CarNames>. Mit CarIDs werden iterative Aufrufe von UI an getCarDetails(CarID) vorgenommen. Früher war der Datentyp CarIDint, der kürzlich zu lange aktualisiert wurde. Javascript hatte eine Beschränkung, um nur bis zu 15-stellige Zahlen zu behandeln, so dass auf der Client-Seite alle Ziffern der Deserialisierung aufgerundet werden. Dies führte zu Ungenauigkeiten in den Ergebnissen.
Lassen Sie mich wissen, wenn es irgendwelche Vorschläge gibt, wie ich eine Validierung/Vertrag im Voraus implementieren kann, um solche Probleme loszuwerden.
Wenn Ihr C# -Controller eine einfache Klasse akzeptiert (nur Eigenschaften, keine Methoden), füllt der Mapper das Objekt ordnungsgemäß aus. Es kann sogar Arrays und verschachtelte Daten akzeptieren. –