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.

ASP.NET MVC 5 Grundkurs

Analyse der automatischen Vorlagen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Ist die komplette CRUD-Funktionalität (Create/Read/Update/Delete) "von Hand" erstellt, werfen Sie einen abschließenden Blick auf die bei "Code First" automatisch erstellten Controller und Views, die einen ganz ähnlichen Ansatz verfolgen.
07:58

Transkript

Nach den ganzen Techniken, die wir uns angesehen haben, wollen wir abschließend noch einmal zurückgehen an den Anfang. Wir hatten ja, an der Stelle mit Code First gearbeitet und dieses automatisches Folding von Visual Sdudio und dem Entity Framework verwendet. Das heißt, uns wurden sowohl alle Views erstellt, als auch der komplette Controller und da wollen wir jetzt mit dem Wissen, das wir gesammelt haben, einfach noch mal hineinschauen und das kurz analysieren. Wir haben die Code First Views, fangen wir vielleicht mal mit der Index.cshtml an, also der Liste und sehen hier in der Tat nichts besonderes. Wir haben einen Link zum Neuerstellen geht also auf die Create Action Methoden im Controller, wir erhalten jeweils die Beschriftungen für Vorname, Nachname, Geburtsdatum, per ForEach Schleife iterieren wir über alle Daten, die uns übergeben worden sind im Modell, Das Modell ist natürlich typisiert, denn wir haben eine View "IEnumerable" von unserem Personentyp, ja, und dann wird für jeden Eintrag in dem Modell einfach der zugehörige Wert ausgeben, der für Vornamen, der für Nachnamen, der für das Geburtsdatum und diese DisplayFor Methode, die dann diesen Lambda-Ausdruck als Parameter nimmt, gibt einfach aus. Das heißt, das übernehmen wir direkt. Ja, und ansonsten haben wir noch Bearbeiten, Detailansicht und löschen Links jeweils, die per AktionLink ausgegeben werden und die ID dieses Elements erhalten. [Unverständlich] hier sagen einfach nur an, dass wir standardmäßig sozusagen keine ID zur Verfügung haben, aber Modelle sind natürlich vorhanden. Bei der Detailansicht ist es relativ ähnlich, so wie wir es auch gemacht haben, typisiert abhängig von Personen und auch hier wird wieder die Beschriftung angegeben und dann ja der eigentliche Wert, und zwar für Vornamen für den Nachnamen und für das Geburtsdatum. Dazu gib es noch ein paar Randlinks nämlich zum Bearbeiten und wieder zurück zur Übersicht. Beim Neuanlegen haben wir wieder typisierte View, Typ Personen, ein Formular haben dieses Sicherheitstoken, haben entsprechend auch die Validierungsregeln auch die Validierungsregeln werden direkt aus dem Modell gezogen, man kann nämlich über Attribute bestimmte Validierungsfeatures angeben, wie etwa dieser Wert muss angegeben werden, dieser Wert muss in einem bestimmten Bereich liegen, diese Eingabe muss eine bestimmte Länge haben etcetra und das wird dann eben auch automatisch mit überprüft und wenn ein Fehler auftreten würde, würde der Fehler hier automatisch ausgegeben werden. Funktioniert also auch hier Out of the Box, es gibt eine Beschriftung und es gibt eine entsprechende Anzeige ja und auch hier wieder Vorname, Nachname, Geburtsdatum, auch hier keine großen Überraschungen, Link zurück zur Liste, beim Bearbeiten ähnlich typisierte Cshtml-Datei Typ Person, Formular, auch hier wieder Beschriftung und ein Bearbeitungsfeld, ja, also auch keine Überraschung und abschließend haben wir noch den Dialog zum Löschen, auch hier wieder typisiert auf Personen, die Personeninformationen werden uns angezeigt und wir haben dann entsprechend unser einfaches Formular. Nun, was passiert denn? Im zugehörigen Controller, wir haben ja Code First Controller genannt und er hat sich jetzt hier geöffnet, machen mal Vollbild, weil ist doch relativ lang und der wurde komplett automatisch umgesetzt und erzeugt, das heißt, hier steht kein eigener Code sozusagen drin, das haben wir hier, wir haben unsere Index-Methode über den Person-Context, das war das Relikt sozusagen von Code First holen wir uns entsprechend Verbindung zu den Personen, erzeugen dann eine Liste aus allen Personen in unserem Repository und geben das zurück bei der Übersicht erhält diese Liste, beim Detailansehen schauen wir auch hier wieder ist die ID vergeben oder angegeben worden als Teil der URL, wir oben zu sehen, falls nein unter dem Fall wird tatsächlich ein HTTP-Status Fehler ausgegeben, das erfolgt also keine einfache Weiterleitung auf die Übersichtsseite, und zwar der Status-Fehler für BadRequest, also HTTP-Status für 400. Und was dann eben als Fehlermeldung-Browser erscheint oder vielleicht vom Webserver abgefangen und durch eine etwas schöne Fehlerseite versetzt wird. Wir suchen eine Person, wenn wir die Person nicht finden, wird HttpNotFound zurückgegeben also HTTP-Code 404, es ist also hier mehr am Restprinzip entlanggehangelt, also auch keine standardmäßige Weiterleitung auf die Übersicht, na ja und wenn wir eine Person haben, wir die an die zugehörige View übergeben. Beim Erstellen wird die Maske ganz normal erzeugt und wenn wir dann per Posts die Erstellungsdaten schicken, dann wird die entsprechende Create Methode aufgerufen. Diese Create Methode erhält die Person, übergeben, und dann wird eben geschaut, ist da alles in Ordnung, falls ja, speichern, und Umleitung auf die Übersichtseite, ansonsten nochmal Ansicht des Erstellendialogs. beim Bearbeiten ähnlich. Wir übergeben die ID des zu bearbeitenden Eintrages, wenn es die nicht gibt, BadRequest. Wenn wir die Person nicht finden, NotFound, ansonsten Ansicht für die Person, wird also die entsprechende View geladen, nur mit den Personendaten bestückt. Bei der Verwendung von HttpPost, können wir dann eine Person bearbeiten, die wird auch direkt übergeben an die Methode, klassische Abfrage, wenn der Zustand gültig ist, dann sagen wir gut, der Zustand des Elements ist Modified, also speichern wir das Ganze und zurück geht es zur Übersicht. Ansonsten zeigen wir nochmal die Maske an mit den aktuellen Personendaten. Beim Löschen bekommen wir wieder eine ID. Sollten wir doch keine bekommen, BadRequest, sollte es die Person zu dieser ID nicht geben, HttpNotFound, na ja und am Ende geben wir wieder die Kontrolle weiter zur View, die die Daten dann anzeigt, falls es die Person tatsächlich gibt, wird das Ganze dann per HttpPost verschickt, dann holen wir uns die Person, löschen sie, speichern, gehen zurück zur Liste. Hier ist jetzt keine Sicherheitsabfrage mehr drin, Hintergrund ist, dass es hier ja eh dieses Sicherheitstoken gibt, was verhindern soll, dass eine Anfrage auf bestimmte Art und Weise manipuliert worden ist und deswegen schließt hier die Vorlage aus, dass wir auf einmal eine andere ID übergeben. Man könnte natürlich trotzdem gemäß dem Motto Tiefenverteidigung eine zusätzliche Überprüfung einbauen, gibt es diese ID tatsächlich? Ja, und im Wesentlichen ist es das gewesen. Das heißt, hat eigentlich alles wunderbar funktioniert, wie auch geplant und ließ sich eben sehr sehr einfach integrieren in Visual Studio und somit haben wir auch sehr gut gesehen, wie ASP.NET funktioniert. Wir haben jetzt eine Sache gemacht, die vielleicht ein bisschen unüblich ist. Wir haben zwei Datenbankzugriffsmethoden oder zwei Modell/Datenbankzugriffsmethoden gleichzeitig ausprobiert, sowohl Code First als auch Database First hatten dabei auch denselben Datentyp. Das ist natürlich normal was nicht passieren sollte und am Ende läuft dann möglicherweise auch nur ein dieser beiden Varianten, die kollidieren ja ein bisschen. Das war nur hier der didaktische Trick, um eben das doppelte Anlegen von so einer Entität zu vermeiden. Wählen Sie also prinzipiell einen dieser Ansätze aus, ziehen Sie ihn konsequent durch, und wie gesagt, wenn Sie einmal entweder die Datenbank haben generieren lassen oder einmal von einer generierten Datenbank aus das entsprechende Entity Data Model erstellt haben, ab dann ist es immer dasselbe. Dieser Controller hier arbeitet mit unserem Kontext den wir erzeugt haben, der Controller, der im Rest des Videotrainings zum Einsatz kam, der basiert auf dem Entity Data Model. Die Ansteuerung war, nachdem man einmal den Kontext oder die Entitäten instanziiert hatte, immer komplett derselbe.

ASP.NET MVC 5 Grundkurs

Machen Sie sich mit den Grundlagen von ASP.NET MVC 5 vertraut und lassen Sie sich in dieser anspruchsvollen Einführung diesen Architekturansatz von Microsoft erläutern.

2 Std. 30 min (20 Videos)
Hui :-)
André S.

Das war sehr interessant. Sowohl MVC selbst als auch der Vortrag. Vielen Dank! Auf eine Fortsetzung würde ich mich freuen - insbesondere wie man komplexere dynamische Views mit Razor bauen kann (verwenden komplexerer Controls (Grid, Combobox etc. incl. Databinding), dynamisches daten- oder statusabhängiges abhängiges Ein- und Ausblenden von Controls sowie Positionieren von Controls und ClientsideEvents unter MVC.

 

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!