Ich schreibe eine einfache "todo - helloworld" mit jqueryMobile + knockout + breeze + WebAPI SPAs (Single Page Application) in einem mobilen Kontext (unzuverlässige Internetverbindung) zu lernen
Um die Offline-Nutzung zu aktivieren, nutzt die WebApp
Die App sollte wann immer möglich entfernte Datenbank zum Laden und Speichern von Daten verwenden, sollte aber in der Lage sein, nahtlos zum lokalen Speicher zu wechseln und lokale / entfernte Änderungen zu synchronisieren, wenn sie wieder online sind.
Nun zurück zu der Frage: Die App wird Breeze EntityManager für die Verwaltung von Daten verwenden (lokaler Cache und Remote-Synchronisierung)
Um Inkonsistenzen / Nebenläufigkeitsprobleme zu vermeiden, würde ich 2 lokale Speicherschlüssel verwenden:
also wäre der Fluss mehr oder weniger (Pseudocode):
%Vor%Was halten Sie von diesem Ansatz? Ist es ein Durcheinander? Ist es o.k? Was ist mit Concurrency-Problemen in einem Multi-User-Szenario?
Das scheint vernünftig, nicht ganz sicher, warum Sie zwei localStorage-Schlüssel wollen. Der EntityState (unmodifiziert, modifiziert, hinzugefügt, gelöscht) jeder in localStorage platzierten Entität wird beibehalten, sodass Sie immer nur die ausstehenden Änderungen von jeder lokalen Kopie "extrahieren" können (siehe die EntityManager.getEntities-Methode). Warum speichern Sie nicht einfach den gesamten Status von entityManager in localStorage, bevor Sie die App herunterfahren?
Bei Concurrency-Problemen sollten Sie auf jeden Entitätstyp definitiv eine Parallelitätseigenschaft festlegen. Solange dies der Fall ist und Sie über das Entity Framework speichern, erkennt Brise während des Speicherns alle optimistischen Parallelitätsverletzungen und löst eine Ausnahme aus. Offensichtlich haben Sie nach einer solchen Ausnahme das richtige Verhalten für Ihre App festgelegt.
Ich bin sicher, Sie haben es gesehen, aber die QueryOptions.MergeStrategy (PreserveChanges, OverwriteChanges) kann sehr hilfreich sein, um Daten auf dem lokalen Rechner nach jeder Abfrage zu behalten oder zu überschreiben.
Ich denke, Sie haben Recht, wenn Sie lokale Änderungen an einem anderen Ort aufbewahren als bei denen, die mit dem Server synchronisiert werden. Ich habe dieses Problem seit ein paar Monaten angepackt und habe mir etwas ausgedacht, das einem Versionskontrollsystem sehr ähnlich sieht, wo alle Daten in einem Schlüssel innerhalb eines Satzes und alles separat versioniert ist. Sie können Änderungen vom Server in die lokale Datenbank herunterladen und sie wird behandelt, wenn sie auf beiden Seiten durch einen Konfliktlösungs-Callback geändert wurden.
Im Moment weiß ich nicht viel über Knockout, aber die Bibliothek selbst ist nicht von irgendwelchen separaten Projekten abhängig und gibt Testfälle in Node.JS, Dojo und jQuery weiter. Es hat eine sehr enge API (.get, .set, .feed (zum Laden heruntergeladener Daten vom Server) und .getFirst (um Zugriff auf das zu bekommen, was hochgeladen werden muss).
Die URL ist Ссылка , sie hat eine ziemlich umfangreiche Demo und Dokumentation.
Tags und Links local-storage singlepage single-page-application breeze data-synchronization