ASP.NET Model View Controler (ASP.NET MVC)

Eintrag zuletzt aktualisiert am: 19.11.2016

Das ASP.NET Model View Controler Framework ist eine Implementierung des MVC-Pattern für ASP.NET zur Erstellung von Websites mit .NET. Das MVC-Framework ist keine Ablösung des bisherigen ASP.NET Webform-Modells, sondern eine Ergänzung.

Namensraum: System.Web.Mvc

Links

Paket: https://www.nuget.org/packages/Microsoft.AspNet.mvc
Website: http://www.asp.net/mvc

Versionen

• ASP.NET Model View Controler 1.0 ist erschienen am 13.09.2009
• ASP.NET Model View Controler 2.0 ist erschienen am 10.03.2010
• ASP.NET Model View Controler 3.0 ist erschienen am 13.11.2011
• ASP.NET Model View Controler 4.0 ist erschienen am 15.12.2012
• ASP.NET Model View Controler 5.0 ist erschienen am 17.10.2013
• ASP.NET Model View Controler 5.1 ist erschienen am 17.01.2014
• ASP.NET Model View Controler 5.1.2 ist erschienen am 04.04.2014
• ASP.NET Model View Controler 5.2.0 ist erschienen am 01.07.2014
• ASP.NET Model View Controler 5.2.2 ist erschienen am 28.08.2014
• ASP.NET Model View Controler 5.1.1 ist erschienen am 10.12.2014
• ASP.NET Model View Controler 5.2.3 ist erschienen am 09.02.2015

Nachfolger ist ASP.NET Core Model View Controler (ASP.NET Core MVC) in ASP.NET Core.

Konzept

Das Model-View-Controler-(MVC)-Framework ist ein Instrument für Mehrschicht-Puristen mit klaren Vorteilen im Bereich Schichtentrennung (Kompetenztrennung in Datenhaltung, Ansicht und Benutzerinteraktion), Testbarkeit, Kontrolle über die Ausgabe und einfachen URL.

Dies geht allerdings in der ersten Version des ASP.NET-MVC-Frameworks unverhältnismäßig stark auf Kosten des Komforts für den Entwickler, denn das MVC-Framework setzt nicht auf den bestehenden komfortablen ASP.NET-Steuerelementen auf, sondern basiert auf Platzhaltern in HTML-Tags (<%= … %>) wie einst die klassischen Active Server Pages (ASP) aus dem Zeitalter vor .NET. Wer eine Tabelle ausgeben will, kann sich also nicht auf die Abstraktion des GridView-Steuerelements stützen, sondern muss die HTML-Tags <table>, <tr>, <td>, etc. verwenden und die zugehörige Schleife über die Datensätze explizit programmieren. Auch die Seitenzustandsverwaltung mit dem ASP.NET-Viewstate ist in MVC-Seiten nicht möglich. Viele andere, nicht an Steuerelemente gebundene Dienste von ASP.NET wie die Authentifizierung, Benutzerverwaltung, Sitzungsverwaltung, Zwischenspeicherung, Laufzeitüberwachung usw. stehen aber im MVC-Framework zur Verfügung.

Nachdem Webentwickler jetzt seit sechs Jahren von dem Rendering der ASP.NET-Serversteuerelemente verwöhnt wurden, ist das MVC-Framework ein schlimmer Rückfall in die Steinzeit. Seiten nach dem MVC-Modell haben neben der klaren Strukturierung nur einen weiteren Vorteil: Sie sind performanter - aber nicht wegen MVC im eigentlichen Sinne, sondern wegen des Verzichts auf die Serversteuerelemente. Für die meisten Anwendungsfälle ist das seit ASP.NET 1.0 bestehende Webforms-Modell mit der Abstraktion durch Serversteuerelemente und Viewstate schnell genug. Es ist absolut unverständlich warum Microsoft die Kombination aus Serversteuerelementen und MVC-Pattern auf eine "spätere Version" vertagen will.

Details zu ASP.NET MVC

Während bei den dynamischen Datenwebsites (Dynamic Data Websites) eine schnelle Lösung die oberste Maxime ist, zielt Microsoft mit dem im März 2009 veröffentlichten ASP.NET Model View Controller Framework (Namensraum System.Web.Mvc) auf klare Kompetenztrennung in lose gekoppelten, beliebig vielen Schichten, gute Test- und Wartbarkeit, die genaue Kontrolle über die Ausgabe und möglichst einfache, d.h. parameterlosen URLs.

ASP.NET MVC folgt dem allgemeinen MVC-Ansatz. Das Modell besteht aus Geschäftsobjekten, Logik und Datenzugriff. Views erzeugen die Benutzerschnittstelle und Aufgabe der Controller ist es, auf Benutzerinteraktionen zu reagieren und die dazu passenden Daten aus dem Modell mit den Views zusammenzubringen. Als Modell können wieder LINQ-to-SQL oder das ADO.NET Entity Framework zum Einsatz kommen – das ist dann aber auch schon die einzige Gemeinsamkeit mit den dynamischen Datenwebsites.

Controller sind Klassen, die von System.Web.Mvc.Controller abgeleitet sind und Aktionen in Form von Methoden implementieren. Sie nehmen die HTTP-Anfrage entgegen, wobei die Standardform /Controller/Aktion/Daten ist. So würde also http://Server/Flug/Edit/103 in der Controller-Klasse Flug die Methode Edit() mit dem Parameter 103 aufrufen. Die Handhabung der vom Benutzer eingegebenen Daten würde eine gleichnamige Methode mit einem Parameter vom Typ FormCollection erledigen (siehe Listing 7).

Den größten Unterschied zu den dynamischen Datenwebsites und auch den ASP.NET-Webforms merkt man allerdings in den Views, denn für das MVC Framework gibt es nicht die komfortablen ASP.NET-Webserversteuerelemente. Stattdessen fällt MVC zurück in die Welt von puren HTML-Tags und eingewobenen Platzhaltern (< % = … % >) wie einst die klassischen Active Server Pages (ASP) und heute noch PHP.

Wer eine Tabelle ausgeben will, kann sich also nicht auf die Abstraktion des GridView-Steuerelements stützen, sondern muss die HTML-Tags <table>, <tr>, <td> etc. verwenden und die zugehörige Schleife über die Datensätze explizit programmieren. MVC stellt lediglich zur Ausgabeerzeugung eine sehr bescheidene Anzahl von Hilfsroutinen wie Html.TextBox(), Html.DropDownList() und Html.ActionLink() zur Verfügung, die aber nur wenig Hilfe sind. Auch die Seitenzustandsverwaltung mit dem ASP.NET View State ist in MVC-Seiten nicht möglich, d.h. der Entwickler muss sich nun wieder selbst darum kümmern, dass zwischen zwei Aufrufen der gleichen Seite der Zustand der Seite wiederhergestellt wird. Auf der Haben-Seite notiert man dafür aber zum einen die volle Kontrolle über das erzeugte HTML und zum anderen die Vermeidung des erzwungenen Aufblähens der Webseite durch die Zustandsverwaltung.

Die Views sind hierarchisch im Dateisystem organisierte .aspx-Dateien, denen aber die sonst in ASP.NET üblichen Code-Behind-Dateien fehlen. Listing 8 zeigt einen einfachen View zur Bearbeitung bestehender Flug-Objekte. Erwähnt sein muss auch noch, dass es für die Views derzeit keinen Designer in Visual Studio gibt; hier ist also Handarbeit angesagt. Zwar spricht Microsoft auch bei MVC von Scaffolding, meint hier aber anders als bei den dynamischen Datenwebsites eine einfache Codegenerierung zur Entwicklungszeit, die man in Visual Studio für Controller und View anstoßen kann.

Viele andere nicht an Webserversteuerelemente gebundene Dienste von ASP.NET Webforms wie die Vorlagenseiten, Authentifizierung, Benutzerverwaltung, Sitzungsverwaltung, Zwischenspeicherung, Laufzeitüberwachung und Sitemaps stehen aber im MVC Framework zur Verfügung.

Public ActionResult Edit(int id)
{
// Zu aktualisierender Flug aus Datenbank holen
var movieToUpdate = _db.Flug.First(m => m.FlugNr == id);

ViewData.Model = movieToUpdate;
return View("Edit");
}

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(FormCollection form)
{
// Zu aktualisierender Flug aus Datenbank holen
int id = Int32.Parse(form["FlugNr"]);
Flug flug = _db.Flug.First(m => m.FlugNr == id);

// Deserialisieren
TryUpdateModel(flug, new string[] { "Abflugort", "Zielort" }, form.ToValueProvider());

// Validieren
if (String.IsNullOrEmpty(flug.Abflugort))
ModelState.AddModelError("Abflugort", "Abflugort is required!");
if (String.IsNullOrEmpty(flug.Zielort))
ModelState.AddModelError("Zielort", "Zielort is required!");

// Speichern
if (ModelState.IsValid)
{
_db.SaveChanges();
return RedirectToAction("Index");
}

// Sonst, zeige Eingabeformular erneut an
return View(flug);
}
Listing 7: Ausschnitt aus dem Controller "Flug"

<form method="post" action="/Flug/Edit">
<%= Html.Hidden("FlugNr")%>
FlugNr:
<br />
<%= Model.FlugNr %>
<br />
Abflugort:
<br />
<%= Html.TextBox("Abflugort")%>
<br />
Zielort:
<br />
<%= Html.TextBox("Zielort")%>
<br />
<input type="submit" value="Save Flug" />
</form>
Listing 8: View "/Flug/Edit.aspx" zur Eingabe von Flugdaten