Ich untersuche gerade clientseitige Modellbindung an HTML-Templates, insbesondere mit angularjs. Ich habe mich gefragt, wie die beste Strategie zum Abrufen clientseitiger Viewmodels vom Server ist, z. ein Viewmodel, das nicht nur die zu bearbeitenden Daten, sondern auch die Daten für Auswahllisten oder Dropdown-Listen usw. enthält.
Wie ich es sehe, hat man mehrere Möglichkeiten
Ich habe nicht viele Beispiele für Option 1 gefunden, da es scheint, dass Web-API hauptsächlich für Crud-Operationen verwendet wird, die spezifische Daten für einen Objekttyp, z. Person oder Bestellung
Option 2 entspricht der Praxis von Server-Side-View-Modellen mit asp.net mvc, aber ich habe nicht viele Beispiele gesehen, die diese Technik in Kombination mit angularjs verwenden
Option 3 sieht sauber aus, wenn man die Trennung von Bedenken berücksichtigt, hat aber den Nachteil mehrerer kleinerer Ajax-Anfragen.
Könnten Sie Ihre Gedanken und Erfahrungen teilen?
Ich stimme mit st überein. nie und habe definitiv Option # 3 verwendet und ich denke, die Kombination aus Ressourcen- und Web-API wäre eine perfekte RAD-Kombination. Ich habe jedoch auch an sehr komplexen Bildschirmen gearbeitet, wo ich Antwortzeiten in Sekundenschnelle haben wollte, also habe ich die gesamte 'Spalte' der Entwicklung optimiert - ich entwickle SQL Server als meine Backend-Datenbank, also habe ich sie benutzt native Unterstützung für XML, um strukturiertes XML aus einer gespeicherten Prozedur zurückzugeben, die ich dann in ein .Net-Modell (POCO) serialisiert, das ich dann an einen Json-Serialisierer zur Übertragung an den Browser übergebe. Ich habe vielleicht eine zusätzliche Geschäftsverarbeitung, die gegen das POCO ausgeführt wird, aber dies führt immer noch zu einer sehr einfachen Codestruktur, um eine ziemlich komplexe Struktur von Daten zu übertragen. In der Regel ist es auch sehr schnell, weil ich einen Aufruf an die Datenbank gemacht habe und die Überwachung und Optimierung einer gespeicherten Prozedur sehr einfach ist.
Persönlich verwende ich Option # 3. Die App würde Anfragen zum "Vorbereiten des Editors" machen, wie das Auffüllen von Dropdown-Listen und Anfragen zum Abrufen der Daten, die Sie bearbeiten möchten (oder, wenn Sie ein neues Objekt erstellen, irgendwelche Standard-Initialwerte). Ich denke, das trennt Bedenken besser als Option 1, die "Modell" -Daten und "Unterstützungs" -Daten miteinander verknüpft.
Aber Sie haben darauf hingewiesen, dass dies zu zusätzlichen Anrufen führt und, wenn sie sehr zahlreich sind, die Seite merklich verlangsamen können. (oder erhöhen Sie die Komplexität; auf einer großen Form mit vielen abhängigen Feldern kann die Reihenfolge wichtig werden).
Was ich normalerweise tue, ist, dass der Server eine "kombinierte" API bereitstellt (z. B. /editor/prepare-all ), während auch kleine Stücke bereitgestellt werden (z. B. /editor/prepare-dropdown-1 , /editor/prepare-dropdown-2 ). Wenn der Editor geladen wird, verwenden Sie den kombinierten; Wenn Abhängigkeiten zwischen Feldern bestehen, können Sie nur die Daten für die abhängigen Felder anfordern (z. B. /editor/prepare-dropdown-2?dropdown1-value=123 ). Ich glaube, das hat wenig Einfluss auf die Komplexität des Servers.
Tags und Links asp.net-mvc asp.net-web-api angularjs