Was ist ASP.NET MVC?

Was ist ASP.NET MVC?

Ich habe in meinem vorherigen Artikel kurz erklärt, was MVC ist und was nicht. Da die theoretischen Informationen, die über die MVC-Architektur gesprochen werden sollen, bereits sicher sind, habe ich sie kurz gehalten, aber ab diesem Artikel und von nun an werden wir über das ASP.NET MVC-Framework von Microsoft sprechen. Es gibt viel zu besprechen, beispielsweise anzuwenden.

Wenn Sie herkömmliche ASP.NET-Formulare verwenden und fragen, warum ich ASP.NET MVC verwenden soll. Wenn Sie denken, können Sie anfangen zu lesen.

Nachteile von ASP.NET Forms

ViewState: In ASP.NET-Formularen hat ViewState nette und sympathische Funktionen, aber eine schlechte Seite. Sehr fett. Wie folgt: Wir haben verhindert, dass Formulare, Benutzerinformationen und Status auf herkömmlichen ASP.NET-Seiten beibehalten werden und mit dem Ansichtsstatus sofort verschwinden. ViewState speichert diese Informationen, indem es sie im base64-Format verschlüsselt. (ViewState-Codegenerierungsstruktur) Dies bedeutet, dass zehn oder sogar Hunderte von Kilobyte Daten erstellt werden und die HTML-Ausgabe jedes Mal zur Seite hinzugefügt wird, wenn der Benutzer die Seite besucht und eine Anfrage stellt, wodurch die Größe der Seite erhöht wird. Obwohl die Seite mit zunehmender Größe an den Server gesendet wird, wird sie auch vom Server an uns zurückgegeben. (Postback) Jedes Mal, wenn auf der Serverseite viel Bandbreite verbraucht wird, führt das Öffnen der Seite auf der Benutzerseite zu ernsthaften Verlangsamungen.

Seitenlebenszyklus: Diese Struktur ist ein Mechanismus, der die Beziehungen der Ereignisse zwischen der Clientseite und der Serverseite regelt. Die Struktur, die wir Request-Response nennen, ist eine Struktur, die die Beziehungen zwischen der vom Benutzer gesendeten Anfrage und der vom Server gegebenen Antwort regelt. Es scheint, dass diese Struktur ziemlich kompliziert ist. Wir haben die Möglichkeit, in den Page-Lebenszyklus einzugreifen, aber wenn wir dies tun, werden wir sehr wahrscheinlich auf böse Überraschungen stoßen. So sehr, dass Sie manchmal nicht herausfinden können, warum Fehler auftreten.

Rogue-HTML-Ausgaben: Serverseitige Sprachen liefern HTML-Ausgaben, die wir nicht kennen. Nachdem es auf dem Server in ASP.NET-Seiten interpretiert wurde, wird es als HTML-Ausgabe angezeigt. Unsere Dominanz hier ist jedoch begrenzt, so dass wir möglicherweise nicht in der Lage sind, eine HTML-Seite wie gewünscht auszugeben. Selbst wenn wir die gewünschte HTML-Datei als Bild erhalten, ist es ziemlich schwierig, eine Codebereinigung und HTML-Ausgabe zu erhalten, die den W3-Standards entspricht, und an sich können dumme HTML-Seiten außerhalb der von uns festgelegten Disziplin auftreten. Besonders wenn es um CSS und Javascript geht, kann unsere Frustration zunehmen. Mit der ASP.NET 4.x-Version kann nicht gesagt werden, dass dieses Problem vollständig verschwunden ist, selbst wenn es bis zu einem gewissen Grad gelöst wurde.

Übermäßige Code-Behind-Abhängigkeit: Angenommen, Sie entwickeln eine Webanwendung mit einer mehrschichtigen Architektur (N-Tier usw.). Sie haben die Präsentations- und Business-Ebene getrennt, und gute ASP.NET-Formulare stehen dieser Struktur tatsächlich entgegen. Der Grund ist, dass wir die Codes schreiben müssen, die viele logische Operationen auf der Code-Behind-Seite der Seiten in der Präsentationsschicht ausführen. Unsere geschichtete Architektur? Dies wird es auch schwieriger machen, wenn das Projekt später aktualisiert oder Add-Ons erstellt werden, da eine verstreute Codestruktur auf uns wartet.

Lernen wir das ASP.NET MVC Framework kennen

Bekanntes MVC ist ein seit 1979 bekanntes Software-Architekturmuster und ein Muster (Muster), das in vielen Programmiersprachen verwendet wird. ASP.NET ist ein MVC-Framework, mit dem wir die MVC-Architektur mit ASP.NET verwenden können, das von Microsoft im MVC Framework entwickelt wurde und noch entwickelt wird.

Model-View-Controller-Strukturen und -Aufgaben in ASP.NET MVC.

Modell: Datenverarbeitung mit Ado.Net, Nhibernate oder EntityFramework, die wir für den Datenbankzugriff verwenden, Klassen sowie die Datenzugriffsschicht, dh Datenbankoperationen, befinden sich hier.

Ansicht: Hier ist, was der Benutzer sieht und die Benutzeroberfläche. HTML-, CSS-, Javascript-Codes … Es gibt nichts im Zusammenhang mit dem Workflow im Abschnitt Ansicht. Darüber hinaus wird die Benutzeroberfläche der Anwendung dank des Abschnitts „Ansicht“ vom Kernteil der Anwendung getrennt gehalten, was uns einen Vorteil hinsichtlich des Designs und der Designänderung verschafft.

Controller: Die vom Client (Benutzer) gestellte Anforderung wird von den Controllern erfasst und verarbeitet. In diesem Abschnitt findet der Workflow statt, Benutzerinteraktionen, die von der Benutzeroberfläche kommen, werden ausgewertet, verarbeitet, erforderliche Methoden ausgeführt, Variablen und Objekte erstellt und die Kommunikation zwischen dem Modell und den Ansichtsabschnitten wird bereitgestellt. Die Objekte, die wir in ASP.NET MVC als Controller bezeichnen, sind winzige C # -Klassen, die von System.Web.Mvc.Controller geerbt wurden.
Vergessen wir nicht, dass es für jede Ansicht einen Controller gibt, aber für jeden Controller gibt es keine Ansichtsanforderung.

In der obigen Abbildung sehen wir die Phasen, die zeigen, wie die ASP.NET MVC-Architektur funktioniert.

Zusammenfassend: Die vom Client (Benutzer / Besucher) initiierte Anforderung (Anforderung) wird auf der Controllerseite verarbeitet. Was auch immer getan werden muss, wenn das Modell kontaktiert werden muss, erreicht es die relevanten Objekte, indem es zum Modell wechselt, und nachdem die dortigen Vorgänge ausgeführt wurden, kehrt der Controller zum Controller zurück und wenn nach dem letzten Vorgang auf dem Controller ein Vorgang vorliegt an View übergeben und die Serverantwort, die wir als Antwort bezeichnen, wird als HTML-Ausgabe an uns gesendet.

Wir werden unsere ASP.NET MVC-Anwendungen ab dem nächsten Beitrag starten. Es wird nützlich sein, besonders diejenigen zu lesen, die MVC treffen werden.