Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Node.js für ASP.NET-Entwickler

Der Vergleich der View Engines

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
ASP.NET ASMX kommuniziert über SOAP, wobei hier viele Details im Dunklen bleiben und nicht alles weitergereicht wird. Im Gegensatz dazu unterstützt Node.js/Express.js SOAP nicht. Der Service ist dafür aber leicht verständlich und durchschaubar.

Transkript

In diesem Video lernen wir wieder durch einen Vergleich von Node.js/Express.js mit gängigen ASP.NET, .NET-Technologien, wo die Unterschiede liegen und wo die eine Welt hier wieder in einer anderen Welt gefunden werden kann. Und zwar beginnen wir doch mal beim alten klassischen ASP.NET ASMX. Und zwar baut das Ganze hier hauptsächlich bei Webforms auf. Das wird hier als Standard verwendet. Die Kommunikation findet hier mittels SOAP statt. Der Nachteil ist, dass halt wichtige Details dadurch verborgen bleiben, wie der Service eigentlich funktioniert. Das heißt dann nicht mehr so handlebar. Express.js, also Node.js unterstützt per "default" zum Beispiel kein SOAP. Das Schöne ist allerdings, dass es halt wirklich ersichtlich ist, wie der Service auch tatsächlich funktioniert, das heißt, JSON Conversion ist per Standard verfügbar, das heißt, dass unsere Daten per JSON konvertiert werden. Das ist einfach schon der Standard, was aber der Nachteil sein muss, auch halt bei Wissen und Verstehen, was man zusätzlich sendet, zum Beispiel am Statuscode oder Header-Informationen et cetera. Im Vergleich von WCF das Schöne ist ja, wie der Name schon sagt, Windows Communication Foundation. Die ganze Kommunikation findet hier hauptsächlich statt, was alles konfiguriert wurde, es heißt, man ist extrem viel dabei per XML oder auch im Code an Konfigurationen vorzunehmen, damit erstmal die Kommunikationen funktionieren. Es werden die Transport Logik Schnittstellen über Interfaces getrennt. Das ist, was nicht unbedingt schlecht ist, das ist aus Architektursicht unter .NET ganz gut. Man ist ja sehr stark dann abhängig von der jeweiligen Konfiguration, unterstützt ebenfalls REST, wenn man dann eben nochmal zusätzliche Attribute mitgibt. Also WCF an sich ist ja nicht schlecht. Der schlechte Ruf von WCF ist erst mal der große Aufwand, den man immer betreiben muss, um erstmal einen Standard-Webservice zur Verfügung zu stellen und dass man eben extrem viel konfigurieren muss und dass nicht mehr so leichtgewichtig ausfällt also mit wenig Zeilen Code et cetera. Node.js/Express.js hat sich eben hauptsächlich darauf spezialisiert auf die HTTP-Kommunikation und über Middleware-Erweiterungen. Es ist ebenfalls möglich, dass man ganz einfach per Web-Sockets zum Beispiel kommunizieren kann, et cetera. Also es ist wunderbar modular erweiterbar, und es ist halt einfach leichtgewichtig. TCP-Kommunikation wäre ebenfalls möglich, aber dann braucht man dazu eine separate Implementation und das wäre zum Beispiel bei WCF nicht unbedingt immer zwingend notwendig, das ist halt dann wieder der Vorteil. WCF hat da die Stärke, wo man wirklich sagt, man braucht unterschiedliche Kommunikationswege, und zwar auch mit einem und demselben Code, was auch nicht immer ganz klappt, gerade auch TCP muss ein bisschen anders handhaben, aber es über die WCF erheblich einfacher als wie zum Beispiel Node.js/Express.js. Und na ja! Bei Express.js, wie wir bereits beim vorherigen Video gesehen haben, ist so gut wie fast gar keine Konfiguration nötig. Da sind so viele Standardwerte einfach schon da, die man heutzutage eben einfach braucht. Schauen wir uns mal die Modelle an und vergleichen zwischen ASP.NET MVC und der Web API zu Node.js und Express.js. Erstellt eine API nach Rückgabetyp das Schöne ist also bei dem neuen ASP.NET verschmelzen ja beide Welten zusammen. Vorher hat man die Web API und MVC also den Controller auch getrennt aufbauen müssen, und pro API hat man halt eben eine eigene Schnittstelle entwickeln müssen, verwendet Attribute für keine-GET Funktionen, das bedeutet, alles, was kein-GET ist, muss man zusätzlich mit Attributen versehen, also man muss sehr sehr viel zusätzlich mit Attributen arbeiten. Er hat eine View Engine per Standard integriert, Route-Funktionen sind oft verstreut in unterschiedlichen Dateien, obwohl sie im gleichen Kontext liegen würden, also das bedeutet, man hat ja einmal seine Crowd-Funktion innerhalb von der Web API oder im Controller und es ist halt schwierig, obwohl viele Funktionalitäten gleich sind, alles in einer Datei zum Beispiel auch zur Hand haben. Das Pushen von Daten ist dann auch nur mit SignalR möglich. Also das heißt, man braucht eigene Services dafür und dann die Kommunikation zwischen diesen beiden Welten, dass es halt funktioniert. Es gibt aber Szenarien, wo es einfach zu komplex ist und nicht so einfach vonstattengeht. Allerdings ist ASP.NET MVC und die Web API die Toptechnologien unter der .NET Welt, um hier mit Webservices zu arbeiten, und ja auch serverseitig irgendwo Views zu rendern. Und ja, die Web API an sich ist aber auch sehr ähnlich zu Express.js. Routing Regeln müssen zusätzlich über Route Location festgelegt werden. Man hat einfach etwas mehr zusätzliche Konfiguration, die man bei Express.js zum Beispiel nicht nötig hat. Bei jeder Funktion, die verwendet wird unter Express.js, gibt es ein Verb, das wird also sehr leichtgewichtig gehandhabt. Pushen von Daten ist ebenfalls möglich. Man braucht auch hier ebenfalls eine Erwiterung, Das wäre Socket.io. Socket.io entspricht exakt dem, was wir von SignalR kennen. Allerdings arbeiten die beiden, also Express.js und Socket.io wunderbar zusammen. Es ist also sehr, sehr einfach. Unterschiedliche View Engines können verwendet werden, das heißt man ist nicht nur auf eine einzige angewiesen, sondern man kann dann wirklich aus mehreren auswählen, was für den eigenen Geschmack besser trifft. Unterschiedliche Route Funktionen können der gleichen Datei auch implementiert werden. Das heißt man hat eine Datei, wo man alle Route Informationen mitgibt und das macht es natürlich übersichtlicher. Und die Routing Regeln sind per Standard einfach vorhanden. Also, man hat einfach ein bisschen weniger Konfigurationsaufwand, man kriegt ein bisschen mehr Übersicht als man zum Beispiel bei der ASP.NET MVC oder Web API kennt. Aber rein funktionell sind beide Welten identisch, und beide Welten sind gleich gut. Für mich persönlich, ich habe bei meinen produktiven Projekten einfach mehr bemerkt, dass ich einfach viel schneller und effektiver unter Node.js und Express.js bin, obwohl ich eben eigentlich aus der .NET Welt komme. In diesem Video haben wir einige Vergleiche gesehen zu den .NET Schnittstellen, .NET-Features und zwischen Node.js und Express.js.

Node.js für ASP.NET-Entwickler

Sehen Sie, wie Sie den Umstieg auf auf native JavaScript-Entiwcklung mit Node.js erfolgreich meistern.

2 Std. 52 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:15.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!