Architekturentwurf für eine datengesteuerte Silverlight WP7-App

Ich habe mir etwas Zeit genommen, um Ihre Anforderungen genau zu lesen und notierte mir einige Gedanken als Resonanzboden.

Erstens ist dies für wiederkehrende Aufgaben mit gemeinsamem Verhalten der richtige Weg. Sie sind nicht allein, wenn Sie über dieses Problem nachdenken.

Leute, die eine Menge von dieser Art von Dingen machen, mögen ähnliche Abstraktionen erzeugt haben, aber meines Wissens wurden keine öffentlich veröffentlicht.

Wie weit Sie damit gehen, hängt davon ab, ob Sie es nur für sich selbst und für diejenigen mit sehr ähnlichen Anforderungen verwenden oder ob Sie allgemeinere Fälle behandeln und ein Produkt herstellen möchten, das von einem sehr breiten Publikum verwendet werden kann .

Ich gehe von ersterem aus, aber das schließt nicht die Möglichkeit aus, es als ein Open-Source-Projekt zu veröffentlichen, das weiter entwickelt und / oder gespalten werden kann.

Indem Sie nicht versuchen, alle Möglichkeiten zu berücksichtigen, können Sie bestimmte Annahmen über die Art der Verwendung der Implementierung und insbesondere über die Auswahl des UI-Designs treffen.

Ich denke, insgesamt denken Sie in die richtige Richtung. Während ich einige Ihrer Gedanken auf hoher Ebene gelesen habe, dachte ich, dass einige Dinge vereinfacht werden können (eine gute Sache) und gleichzeitig eine überzeugende Benutzeroberfläche liefern.

Auf Ihre anfänglichen Punkte.

• Sie könnten einfach davon ausgehen, dass eine Performance in einer bestimmten Fortschrittsleiste übergeben wird.
• Tun Sie dies, wenn es Ihnen wichtig ist, aber Sie könnten sich selbst etwas Komplexität aneignen, die sich mit unterschiedlichen Caching-Anforderungen beschäftigt - Varianz in der Dauer oder schmutzige Handhabung. Vielleicht reicht es aus, auf die Plattformen zu bauen, um URLs zwischenzuspeichern (die einige Leute gefunden haben, kommt ihnen in den Weg).
• Handle Netzwerkverbindung, yep das ist sich wiederholend und etwas kompliziert. Ein perfekter Kandidat für eine allgemeine Lösung.
• Update UI ... wohl besser, um einfach Daten zurückzugeben und Entscheidungen bezüglich Präsentation und Format der Daten an Ihre individuellen Kunden zu verschieben.
• Inhalt im Hauptspeicher - siehe oben zum Caching.

Auf Ihre möglichen Eingaben.

• Wo Inhalte angezeigt werden sollen - siehe oben re-Daten und Verschiebungen der Präsentationsauswahl zum Client.
• Ich würde mit einem UI-Element für die Fortschrittsanzeige gehen, wiederum eine performante Fortschrittsleiste. In Bezug auf die Kommunikation des Scheiterns würde ich in Erwägung ziehen, dies in einer Completed-Veranstaltung umzusetzen, die Sie veröffentlichen. Dann können Sie über Parameter das Ergebnis kommunizieren und die Behandlung auf den Client verschieben, um das Ergebnis in eine Präsentationssteuerung / Protokoll / was auch immer zu bringen. Dies entspricht den Mustern, die vom .Net Framework verwendet werden.
• URI - Ja, das wird übersprungen.
• Wie man analysiert - einen Delegaten übergeben, um einen Stream oder eine Zeichenfolge in ein Objekt zu konvertieren, dessen Typ vom Client bestimmt werden kann.
• Lok des Caches - Sie könnten dies weitergeben, wenn Sie dies verallgemeinern oder seinen Pfad hardcodieren. Es wäre nützlicher für andere, wenn es weitergegeben wird (wenn Sie mit Ordnern / Erstellung umgehen).

Zur Implementierung.

• Sie könnten mit einem UserControl gehen, wenn es für Sie funktioniert, an diese Annahme gebunden zu sein. Es wäre jedoch flexibler und wohl ebenso einfach / elegant, die Präsentation sowohl für die Datenanzeige als auch für die Statusmeldungen auf dem Client zurückzuschieben und die Ein- / Ausblendung des Fortschrittsbalkens, der übergeben wurde, zu steuern.
• Vielleicht würden Sie so weit gehen und davon ausgehen, dass die Statusmeldungen immer in einem Textblock angezeigt würden (wenn sie bestanden würden) und diese Verwaltung von jedem Ihrer Clients in Ihre generische Klasse verschieben würde.
• Ich vermute, dass Sie davon profitieren werden, das Datenformat und die Präsentation nicht zu koppeln.
• Tombstone-Handhabung .. Ich würde einige Tests auf den Plattformen im eingebauten Caching von URLs hier empfehlen und sehen, ob Sie feststellen können, ob Dauern / schmutzige Bedingungen für Ihre allgemeinen Fälle funktionieren.

Hoffentlich gibt dir das ein paar Dinge, über die du nachdenken kannst, und eine gewisse Beruhigung, dass du auf dem richtigen Weg bist. Es gibt viele Möglichkeiten, wie du das machen kannst. Welches ist der beste Weg letztlich wird durch Ihre Ziele getrieben werden.

Ich entwickle eine WP7-Anwendung, die im Grunde ein Client einer bestehenden REST-API ist. Der Server gibt Daten in JSON zurück. Mit Hilfe der Bibliothek JSON.NET (http://json.codeplex.com/) konnte ich es direkt in meine .NET C # Klassen deserialisieren.

Ich speichere lokal die Daten, um das Offline-Szenario meiner Anwendung zu handhaben und um den Aufruf auf dem Server jedes Mal zu verhindern, wenn der Benutzer die Anwendung startet. Ich biete zwei Möglichkeiten, um die Daten zu aktualisieren: manuell und / oder nach einer gewissen Zeit. Zum Speichern der Daten verwende ich Sertling (http://sterling.codeplex.com/), es ist eine einfache, aber einfach zu verwendende lokale Datenbank für Silverlight / WP7.

Die größte Herausforderung besteht in der asynchronen Kommunikation mit dem Server. Ich biete klare UI-Rückmeldungen (Progressbar und / oder Loading Wheel) an, um dem Benutzer mitzuteilen, was vor sich geht.

Nebenbei verwende ich MVVM Light Toolkit und SL Unit Testing, um den Integrationstest durchzuführen. View Model = & gt; Mein lokaler Client-Code = & gt; Server. (http://code.google.com/p/nunit-silverlight/wiki/NunitTestsWp7)