ASP.NET MVC - Technologien auf der Client-Seite?

Hallo zusammen

Ich umschreibe kurz unsere Ausgangslage bevor ich auf die eigentliche Frage komme, entschuldigt daher bitte den etwas längeren Text.

Unsere bestehenden (Web-)Lösungen basieren alle auf ASP.NET Web Forms.
Aufgrund der bekannten Nachteile möchten wir zukünftig mit anderen Technologien entwickeln.

Wir haben entsprechend Prototypen erstellt, z.B. mit ASP.NET MVC oder AngularJS+ASP.NET Web API.
Grössere Projekte haben wir aber noch nicht realisiert.

Grundsätzlich gefällt uns ASP.NET MVC sehr. Allerdings haben wir in unseren Projekten viele Anforderungen welche im Client (d.h. JS) gelöst werden müssen.
Beispiele: Lookup-Felder, Auto-Complete, Asynchrone aufrufe, Status-Polling, Nachladen einzelner Daten, usw.

Ich denke die Thematik ist auch bei euren Web-Lösungen bekannt.
Es geht vor allem um die Usability für die Benutzer.

Der Microsoft bzw. ASP.NET MVC Weg hat uns auf den ersten Blick etwas zu viel "Magie". Wir meinen damit z.B. das "async"-Rendern einer Controller-Action (=UpdatePanel?).
Mit AngularJS haben wir erfahren wie gut es ist "bewusst" auf dem Client zu entwickeln und oben genannte Anforderungen sauber zu implementieren.

Nun meine Frage an euch: Wie löst ihr "client-lastige" Anforderungen im Kombination mit ASP.NET MVC?
Nutz ihr parallel die Web API und jQuery/Knockout, oder AngularJS?

Für uns stellt sich auch die Frage ganz auf ASP.NET MVC zu verzichten und Web API/AngularJS zu nutzen.
Allerdings wissen wir die Typsicherheit, Features, IntelliSense, usw. von C# auch sehr zu schätzen.

Gruss Kantiran

Wir haben entsprechend Prototypen erstellt, z.B. mit ASP.NET MVC oder AngularJS+ASP.NET Web API.

Wieso oder? Es gibt hier kein Oder (siehe ganz unten).
Ich mach zB alles mit ASP.NET MVC und AngularJS.
Dabei mische ich das Request-und das SPA-Verhalten und finde es so sehr gut. So gleiche ich die Nachteile des einen mit den Vorteilen des anderen aus.

Der Microsoft bzw. ASP.NET MVC Weg hat uns auf den ersten Blick etwas zu viel "Magie". Wir meinen damit z.B. das "async"-Rendern einer Controller-Action (=UpdatePanel?).

das ist eigentlich falsch, denn im Gegensatz zu WebForms hat MVC gar keine Magie mehr. Es gibt keine Update Panels, sondern Du machst das alles selbst mit Ajax. Du entscheidest, was passiert.
Das ist aus Web-sicht auch der Grund für MVC: Du hast alles zu 100% in der Hand.
Ob async oder nicht spielt für Ajax keine Rolle.

Ich weiß auch nicht, was Du mit async Rendern meinst; denn für das async-Verhalten spielt das Rendern keine Rolle. Wisst ihr denn, was async/await überhaupt ist? 😉
Jedenfalls ist das Rendern in beiden Fällen absolut identisch und da steckt keinerlei Magie dahinter.

async/await ist ein C# Feature, hat mit ASP nichts am Hut. Und ja, darinter steckt Task-Magie, die man verstanden haben muss.

Nun meine Frage an euch: Wie löst ihr "client-lastige" Anforderungen im Kombination mit ASP.NET MVC?

Mein Kern ist immer ASP.NET MVC.
Je nach Anwendung sind die Seiten entweder Request-basierenden oder eben über eigene API-Controller. WebAPI (also den ApiController => REST) selbst nutze ich fast nie, da ich nie zu 100% Restful-arbeiten kann oder will.

Nutz ihr parallel die Web API und jQuery/Knockout, oder AngularJS?

Von jQuery standalone, oder Knockout halte ich nichts.
Ich verwende nur AngularJS/jQuery.

Für uns stellt sich auch die Frage ganz auf ASP.NET MVC zu verzichten und Web API/AngularJS zu nutzen.

WebAPI ist bestandteil von ASP.NET MVC. Du kannst die reine WebAPI gar nicht alleine laufen lassen.
Technisch gesehen (ist meine Grafik, nichts offizielles) sieht das bei mir so aus wie im Anhang. Streng genommen sind ASP.NET MVC und WebApi nicht getrennt, sondern nur in der Logik.

In VS2013 mit WebEssentials hast Du auch in AngularJS und jQuery Intellisense.

Ob ihr nun eine SPA oder eine Request-Seite haben wollt: das sollte nicht die Entwicklung entscheiden, sondern das Bedürfnis der Kunden decken.
Wenn die keine SPA haben wollen (denkt an das Routing-Verhalten!) dann fliegt eine reine SPA sowieso raus.

Hallo Abt

Vielen dank für dein Feedback. Du hast anscheinend schon einige Praxis-Erfahrungen gemacht.
Ich habe mich in einigen Punkten etwas unklar ausgedrückt. Natürlich sind uns die entsprechenden Technologien (await, WebAPI, etc.) bekannt.

Die von dir erwähnte Kombination von MVC und AngularJS sehen wir auch als einen möglichen (optimalen) Weg.
Zumindest für eine "klassische" daten-getriebene Webanwendung. Im Mobile-Bereich (v.A. wenn sie offline-fähig sein soll) sehen wir eine reine AngularJS-SPA mit WebAPI als ideal an.

Darf ich hier noch etwas genauer nachfassen?

Wie löst du denn eine "Client-Funktionalität", d.h. zum Beispiel eine Angular-Directive welche mittels $ressource Daten lädt/anzeigt?
Über folgende Themen machen wir uns in dem Kontext Gedanken:*Performance: Ist es ein Problem wennn AngularJS (+Abhängigkeiten) bei jedem Seitenaufruf geladen werden? *Projektstruktur: Wie integrieren wir die Angular-Elemente optimal in die MVC-Projektstruktur? *Wie entscheiden wir wann etwas Server-Side (MVC) oder Client-Side abgebildet wird? *Wie können wir Client-Komponenten wiederverwenden (-> z.B. mit NuGet)? *Wie verhindern wir Redundanzen zwischen Client/Server (z.B. Übersetzungen, Validierungen, usw.)?

Mir ist klar dass die Antworten teils von der konkreten Projekt- bzw. Kundenanforderungen abhängig sind.

Es geht uns aktuell vor allem darum die Architektur möglichst einfach und klar zu halten. Dies ist für eine hohe Qualität wichtig (v.A. bei vielen Entwicklern).
Denn sobald es in einer SW mehrere Möglichkeiten/Technologien gibt um "das Gleiche" zu Entwickeln wird dies auch passieren.

Wir befürchten einfach dass wir im schlimmsten Fall nach Jahren einen "undefinierten Mix" zwischen MVC-Controllern, -@Helpern und Angular-Elementen erreichen.
Wenn z.B. 70% mit Angular gelöst wird können wir MVC gleich aussen vor lassen.

Gruss Kantiran

Hi Kantiran,

Wir befürchten einfach dass wir im schlimmsten Fall nach Jahren einen "undefinierten Mix" zwischen MVC-Controllern, -@Helpern und Angular-Elementen erreichen.

Das eine ist die Server-Anwendung (C# + MVC) und das andere die Client-Anwendung (JS + Angular). Daher ist die Trennung sehr strikt und kein undefinierbarer Mix. Die Entscheidung, welche Features auf dem Server und welche auf dem Client implementiert werden, fällt daher eigentlich sehr leicht. Validierungen sollten möglichst auf beiden Seiten verfügbar sein, auf dem Client wegen der Nutzerfreundlichkeit und auf dem Server wegen der Sicherheit.

Wenn du Angular (oder eine beliebige andere Bibliothek) auf mehreren Seiten einbindest, dann wird sie bei jedem Seitenaufruf entweder vom Server oder aus dem Cache geladen. Das sind aber alles Sachen, die eigentlich unter [Hinweis] Wie poste ich richtig? Punkt 1 fallen.

Wenn z.B. 70% mit Angular gelöst wird können wir MVC gleich aussen vor lassen.

Und die restlichen 30%? Oder anders gefragt: Woher kommen dann die Daten, mit denen Angular arbeiten soll?

Christian

Vielen dank für dein Feedback. Du hast anscheinend schon einige Praxis-Erfahrungen gemacht.

Ja 😉

Wir befürchten einfach dass wir im schlimmsten Fall nach Jahren einen "undefinierten Mix" zwischen MVC-Controllern, -@Helpern und Angular-Elementen erreichen.
Wenn z.B. 70% mit Angular gelöst wird können wir MVC gleich aussen vor lassen.

Es geht uns aktuell vor allem darum die Architektur möglichst einfach und klar zu halten. Dies ist für eine hohe Qualität wichtig (v.A. bei vielen Entwicklern).
Denn sobald es in einer SW mehrere Möglichkeiten/Technologien gibt um "das Gleiche" zu Entwickeln wird dies auch passieren.

Ihr seid meiner Meinung nach schon viel zu weit. Ihr müsst doch viel weiter vorher planen. Sowas nennt man Evaluierung, zu der auch die Skalierung gehört.

Ihr müsst euch einig werden, was ihr für eine Anwendung haben wollt.
Im Prinzip gibt es 3 Arten.

1. vollständig Server-seitig (optional mit dem Verzicht auf Javascript). Läuft auf allen Clients.
   Jede Aktion der Veränderung erfordert einen Submit an den Server und das jeweilige Neuladen der gesamten Seite. Sowas ist das Forum hier.

2. ihr wollt eine Single Page Application: SPA.
   Es wird ein einziges mal ein initialer Request durchgeführt; alles andere sind dynamische Daten. Kommt sogar theoretisch vollständig ohne eigenen Webserver aus, da alles im Client berechnet wird. Die APIs können irgendwo extern sein (Twitter, Instagram Whatever...).
   Sowas sind oft Apps auf Konsolen oder TVs.
   Im Web ist mir nur eine einzige deutsche große Seite bekannt: http://www.fussball.de/
   Nahezu vollständige SPA Anwendung.

3. Ein Mix. Es ist eine qualifizierte Server-Technologie zum Beispiel ASP.NET MVC um Einsatz. Einzelne Elemente der Seite sind dann wiederum komplett modular und ähneln sich SPA-Seiten.
   Sprich einzelne Teile der Anwendung sind SPA; andere nicht.
   Sowas ist so ziemlich jede größere Seite. Facebook, Twitter, Instagram und im deutschen Raum die Großen: Check24, HRS, die meisten Seiten des Springerverlags.

Wenn Du Dich entschieden hast, was Du willst, dann kannst Du entscheiden, welche Technologien Du nehmen möchtest. So wie es sich anhört, habt ihr bock auf irgendwelche Technologien, auch wenn der Nutzen des Endusers noch gar nicht klar ist.
Sowas fährt oft gegen die Wand 😉 Muss nicht. Aber kann.

Ich würde immer auf Variante 3 setzen.
Das ist auch relativ einfach wieso:*Es ist im DACH Raum viel einfacher geeignetes Personal für Mix-Anwendungen zu finden, als wirkliche SPA Profis. *Ich hatte noch nie den Fall, dass alle meine APIs völlig auf REST basieren können. Es ab immer irgendwelche Komplikationen, die dies nicht erlaubt haben. Ohne geeigenete Server-Technologie wäre ich im Regen gestanden. So kann ich aber sehr flexibel reagieren.

Eine moderne RIA Anwendung besteht nicht nur aus einer Anwendung (auf dem Server), sondern aus zwei Anwendungen: auf dem Server und auf dem Client.
Beide können optimalerweise vollständig alleine agieren.
Sie kommunizieren eben über APIs.
Du könntest die Serverseite von ASP auf PHP ändern; oder eben den Client von Knockout auf AngularJS - wenn es sauber umgesetzt wird.

Wie löst du denn eine "Client-Funktionalität", d.h. zum Beispiel eine Angular-Directive welche mittels $ressource Daten lädt/anzeigt?

Performance: Ist es ein Problem wennn AngularJS (+Abhängigkeiten) bei jedem Seitenaufruf geladen werden?

Grundlagen der Webprogrammierung.
Javascript sind statische Ressourcen und werden vom Client gecached. Was es langsam macht sind die Inits(). Für den Inhalt bist aber Du verantwortlich. Sind diese schnell juckts nicht. Sind diese Umfangreich isses doof.
Ich hab damit keinerlei Probleme. Liefere Seiten i.d.R. unter 50ms aus und der Client merkt nicht, ob das nun ein Neuladen war oder nicht.

Projektstruktur: Wie integrieren wir die Angular-Elemente optimal in die MVC-Projektstruktur?

Keine pauschale Antwort möglich.

Wie entscheiden wir wann etwas Server-Side (MVC) oder Client-Side abgebildet wird?

Wird dadurch entschieden, wie die Bedienung der Anwendung werden soll. Für sowas sind UI-Artists verantwortlich.

Wie können wir Client-Komponenten wiederverwenden (-> z.B. mit NuGet)?

Wat?!

Wie verhindern wir Redundanzen zwischen Client/Server (z.B. Übersetzungen, Validierungen, usw.)?

Überhaupt nicht. Das wäre auch absolut unverantwortlich.
Im Client machst Du normalerweise nur strukturelle Prüfungen. Ist in der E-Mail-Box auch wirklich eine EMail.
Aber was machst Du, wenn derjenige böse ist und die Api direkt called? Du musst IMMER an der API ALLES prüfen. Egal ob SPA oder nicht. IMMER!
Zusätzlich kommt eben die Client-Prüfung hinzu, sodass Du unnötige Calls vermeidest.
Das eine schließt nicht das andere aus - sie ergänzen sich auch nicht. Es ist so zwingend erforderlich.

Vielen Dank für eure Antworten.

Bei der Verbindung von ASP.NET MVC und AngularJS scheint es sich ja um eine gängige Variante zu handeln.
Wir werden entsprechend diese Variante weiter prüfen.
Ich gehe davon aus das zu dem Thema bereits einige Blogeinträge usw. verfasst wurden.

Das Thema ist entsprechend soweit erledigt. Ich melde mich ggf. wieder mit konkreteren Fragen zu einer Implementation. Meine Fragen und entsprechend das Thema sind aktuell etwas zu generell (Evaluierung/"Bock auf Techn."/usw.).

Gruss Kantiran

Was Technologie und Umsetzung angeht, kann ich Abt in seiner Ausführung nur zustimmen.

Ich nutze persönlich auch Variante 3 - mit dem Mix zwischen SPA elementen und hin und wieder Request für "komplett andere Seitendarstellungen".

Mit AngularJS und ASP.NET MVC liegst du aktuell sehr gut - von knockoutJs würde ich aktuell auch eher abraten und lieber direkt auf AngularJS setzten.

MFG
SquadWuschel