CRUD REST API - Wer "erstellt" das C# -Objekt selbst?

Question

Ich habe eine WCF-basierte C# CRUD REST API, die auf Schedule-Objekte funktioniert. Es gibt Methoden zum Erstellen, Aktualisieren und Löschen, wie Sie es erwarten.

Mein Problem ist, dass das Schedule-Objekt ein TriggerInfo-Unterobjekt enthält. Wenn Sie nur den Konstruktor aufrufen, rufen Sie eigentlich den Konstruktor eines Proxys auf, und der echte Konstruktor wird nie aufgerufen, sodass die Unterobjekte nicht initialisiert werden.

Der Proxy, den WCF sendet, hat TriggerInfo als ein Feld, aber es wird immer null sein, da die Konstruktorlogik in der "echten" Klasse nie aufgerufen wird.

Mit anderen Worten, wenn der Client ein C# 'Schedule' -Objekt erstellt, erstellt es wirklich einen Proxy der realen Schedule-Klasse, und der Proxy weiß nichts darüber, etwas initalisieren zu müssen!

Also in dieser Huhn-und-Ei-Situation, wer erstellt das C# 'Schedule' Objekt, das der Client "ausfüllen" kann?

Ich dachte, der C# -Client könnte ein Schedule-Objekt erstellen, füllen Sie alle Eigenschaften und übergeben Sie es an die CreateSchedule() API und es würde funktionieren. Nicht so einfach!

Es würde funktionieren, wenn ich eine große, flache monolithische Klasse erstellen würde, bei der alle TriggerInfo-Eigenschaften stattdessen Eigenschaften des Schedule-Objekts wären, aber nicht sehr sauber, besonders wenn Sie mehrere Unterklassen haben.

Ich könnte ein ScheduleFactory-Objekt in meiner API verfügbar gemacht haben, das weiß, wie man es erstellt, aber ich weiß nicht, ob das ein gültiger Ansatz ist!

Answer 1

nicht Schedule Objekt clientseitige erstellen, wenn es jede nicht-triviale Initialisierung braucht - fügen Sie einfach ein New oder Methode Ihres WCF-Dienst erstellen und tut es Server-Seite. Alternativ können Sie new Schedule() clientseitig verwenden, eine neue Proxy-Instanz mit vielen NULL-Eigenschaften abrufen und diese Eigenschaften mit sinnvollen Standardwerten serverseitig in Speichern Methode eingeben.