Muster für den Umgang mit Firebase-Modellen mit Beziehungen (iOS)

Question

Ich suche nach Mustern in bestehenden iOS-Apps (Swift bevorzugt, aber ich denke, es spielt keine Rolle), um einige Ideen zum Umgang mit Modellen zu erhalten Firebase (oder eine beliebige NoSQL DB). Die Komplikation beruht auf 1) der Art und Weise, in der Firebase auf Änderungen an Daten wartet, und 2) dem Beibehalten der DB-Anforderungslogik aus den Modellen.

Also lassen Sie uns sagen, dass ich so etwas wie dieses:

struct User { 
    let name: String 
    let checkin: Checkin 
} 

struct Checkin { 
    let name: String 
    let coordinates: Double 
} 

Nun, wenn ich entscheiden, ich will Daten in meiner Ansicht-Controller, ich werde wie Database.database()..reference()... etwas tun, und eine Methode für mein Modell haben analysieren, um die JSON und fügen Sie es in das Modell ein. Was passiert nun, wenn es zu einer Beziehungseigenschaft kommt (in diesem Fall checkin beim Erstellen einer Instanz von User)? Wenn ich das vollständige Benutzermodell mit allen untergeordneten Beziehungen haben möchte, werde ich nur etwas wie { checkin: someRandomCheckinId } von Firebase zurückbekommen. I könnte einen anderen Anruf machen, um die Eincheck-ID zu bekommen, aber ich würde diese Logik in meinem Modell tun müssen, wenn die Daten von Firebase zu analysieren, die nicht ideal scheint - es scheint, dass Logik am besten auf der VC gehört (oder eine separate Datenmanagerklasse, die vom VC aufgerufen wird). Gibt es einen besseren Weg?

Außerdem möchte ich in der Lage sein, Änderungen zu hören, da es ein Hauptmerkmal von Firebase ist. Ich kann mir nicht vorstellen, mein Modell mit einem Haufen Zuhörer zu verschmutzen, ist eine gute Sache.

Alle Beispiele von Repos mit einem guten Muster dafür wäre großartig, um meinen Kopf um eine geeignete Lösung zu wickeln. Danke im Voraus!

Answer 1

Diese Frage besteht aus zwei Teilen. Die erste besteht darin, Daten in einem NoSQL-Dokumentspeicher zu strukturieren. Die zweite besteht darin, eine Anwendung in einer modernen OO-Sprache zu strukturieren. Beide erweitern sich gut über die Reichweite von Firebase und Swift.

Für den ersten Teil, der Rat, den ich Ihnen zu Beginn geben würde, ist, dass Sie verwandte Daten für den schnellen Zugriff zusammenhalten sollten. Beim Arbeiten mit diesen Datentypen gibt es normalerweise eine Platzstrafe, wenn Daten dupliziert werden. Dies ist in Ordnung, da der Platz im Vergleich zur Zeit relativ günstig ist. Wenn Sie in Ihrem Beispiel häufig alle "Checkins" erhalten möchten, wenn Sie einen "Benutzer" erhalten, speichern Sie die "Checkins" für einen Benutzer in diesem Benutzer. Wenn Sie es gewohnt sind, mit RDBs zu arbeiten, müssen Sie sich daran erinnern, dass Sie mit dieser Speicherart Datenschichten speichern können und ein Attribut mehrere Werte haben kann. Stellen Sie sicher, dass Sie die Firebase-Dokumentation zum Zugriff auf Daten gelesen haben, da sie einige Empfehlungen zur Speicherung von Daten enthalten, um Zeit und Speicherplatz zu sparen. Die Hauptidee besteht darin, die Daten flacher und nicht zu viele Ebenen tief zu halten. Denken Sie daran, dass das Erwerben eines Elternteils auch alle untergeordneten Elemente erhält. Dies beinhaltet normalerweise einige Datenduplikationen.

Für den zweiten Teil der Frage müssen Sie ein wenig tiefer graben. Beginnen Sie mit dem Lesen der Prinzipien des Software-Engineerings. Die SOLID-Prinzipien sind die wichtigsten, aber es gibt viele andere, an die Sie sich halten sollten. Ein Grundsatz besagt, dass Sie verwandte Daten und Verhaltensweisen zusammenhalten sollten. Ein anderer besagt, dass jedes Modul (Klasse) eine einzige Verantwortung haben sollte (Grund zur Änderung). Die meisten iOS-Entwickler folgen der sehr schlechten Entwicklungspraxis beim Laden der ViewControllers mit der gesamten Anwendungslogik, die viele Prinzipien verletzt. Modellklassen dienen nicht nur zum Speichern von Status, sie sollten auch Verhalten in Bezug auf diesen Status enthalten. Ein ViewController sollte nicht auf eine Datenbank zugreifen und sollte nichts über die Datenbank wissen. Dies sollte irgendwo in Ihrem Anwendungsmodell passieren. Wenn auf Daten für jeden Typ auf eine bestimmte Weise zugegriffen wird, speichern Sie diese Logik mit dem Typ. Wenn vieles davon für alle Typen gleich ist, dann abstrahiere diesen Teil heraus.