Direkt zum Hauptbereich

Nachtrag zum JSON Serialisierer ab Embarcadero Tokio 10.2

In einer meiner letzten Blogeinträge, sprach ich über meine Erfahrungen zu dem noch nicht so ganz vollständig dokumentierten JSON Serialisierer ab Tokio, hier nachzulesen unter Neuer JSOJN Serialisierer ab Tokyo

Bis jetzt hat er mir wertvolle Dienste erwiesen. Er ist ein Serialisierer wie man ihn sich wünscht bzw. kennt. Durch Unittests konnte ich diverse Möglichkeiten austesten. Zum Beispiel wollte ich nicht nur ein dynamisches TArray<T> als Liste exportieren, sondern auch eine TList<T>. Bei der TList<T> wurden aber immer alle Felder ins JSON geschrieben welche ich gar nicht brauchte. Natürlich gäbe es die Möglichkeit einer Ableitung und diese mit Attributen zu versehen aber wieso was neues erfinden. Eine andere aber meiner Meinung nach unschöne, ist das konvertieren einer TList<T> ToArray, ginge auch aber...

Wie man nur einen Teil der vordefinierten Typen serialisieren kann!

In diesem Fall kommt man um ein bisschen Code nicht herum, aber man kann mit TJsonDynamicContractResolver dynamisch Attribute hinzufügen oder entfernen. Wie macht man dies?

function TNathanUDV2Dto.ToJson: string;
var
  Serializer: TJsonSerializer;
  Resolver: TJsonDynamicContractResolver;
begin
  Serializer := TJsonSerializer.Create;
  try
    Resolver := TJsonDynamicContractResolver.Create;
    Resolver.ClearAttributes;
    Resolver.SetFieldsIgnored(TypeInfo(TList), ['FListHelper', 'FComparer']);
    Resolver.SetFieldName(TypeInfo(TList), 'FItems', 'Values');
    Serializer.ContractResolver := Resolver;
    Result := Serializer.Serialize(Self);
  finally
    Serializer.Free;
  end;
end;

Durch SetFieldsIgnored schliesse ich Felder aus, welche ich nicht im JSON haben möchte. Mit SetFieldName gebe ich ihnen einen anderen Namen.

Kommentare

Beliebte Posts aus diesem Blog

MVC mit System.Messaging

In der Vergangenheit hatte ich, beim Einsatz vom MVC Pattern immer eine eigene Implementation des Observer Pattern um Nachrichten vom Model ans View zu schicken. Hierbei handelte es sich um ein einfaches Record welches nur Text verschicken konnte. Das View musste deswegen auch immer das Model, bzw. das Interface des Model kennen um Daten für Aktualisierung zu haben. Dies widerspricht meiner Meinung nach, dem Prinzip von Clean Code "Separation of Concerns" und koppelt das View ans Model. Um dem entgegen zu wirken, experimentierte ich mit den Board-Mitteln Delphi, aus dem Namespace System.Messaging . Im View hänge ich mich an den DefaultManager der Klasse TMessageManager . procedure TFormShowMessage.FormCreate(Sender: TObject); begin FSubscriptionId := TMessageManager.DefaultManager.SubscribeToMessage(TMessage , procedure(const Sender: TObject; const AMessage: TMessage) begin Memo1.Lines.Add((AMessage as TMessage ).Value); end); end; Das Model schickt ...

Neuer JSON Serialisierer ab Embarcadero Tokio 10.2

Seit Embarcadero Tokyo 10.2 veröffentlicht hat, steht uns Entwicklern ein neuer sehr gut zu gebrauchender JSON Marshaller zur Verfügung. Leider ist die Dokumentation dürftig. Das schöne ist aber, das Embarcadero sich ziemlich an gängige Verfahren hält. So konnte ich z.B. sehr einfach herausfinden was TJsonCustomCreationConverter<T> macht, nachdem ich C# Beispiele analysierte. Da es leider keine offizielle Dokumentation zum TJsonSerializer gibt, beruhen meine Beispiele auf Versuch und Irrtum. Es gibt 3 Namespaces, welche relevant sind. Zum einen "System.JSON.Serializers", für den eigentlichen Serialisierer und die Klassenattribute, zum anderen "System.JSON.Converters", für eigene Konverter und zuletzt "System.JSON.Types", für z.B. Datumsformate oder Formatierungen. TJsonSerializer Ist die wichtigste Klasse, sie ist implementiert im Namespace System.JSON.Serializers. Diese Klasse ist dafür zuständig, ein Objekt in JSON (Serialisierung) zu formati...

Wie setzte ich Mocking Frameworks ein um meine Logik zu Testen?

Allgemein Bisher hatte ich zum Mocken meist das  Delphi-Mocks Framework  verwendet, was in den meisten Fällen ausreichte. In dem Post zeige ich, wie man das Mocking von Spring4D verwendet. Der Grund für diesen Post ist, dass es immer noch genügend Programmierer gibt welche noch nie oder viel zu selten Tests schreiben oder einsetzen. Viele reden darüber und erzählen, dass sie "natürlich" Testen. Aber ohne automatische Tests kann man die Qualität sowie einen sauberen Code nicht gewährleisten. TDD (test driven development) hat seine Schattenseiten, aber für jemand der sich nie richtig mit Clean Code, SOLID oder ähnlichem beschäftigt hat, hilft es die Prinzipien einfacher einzuhalten. In jeder Programmiersprache kann ein sauber Code geschrieben werden. Langfristig ist ein schneller, aber unsauberer Code, teurer als einmalig einen sauberen Code zu schreiben. Diese Einsicht ist meiner Erfahrung nach, leider noch nicht bei allen Programmierern angekommen. Tests dienen dazu, da...