ASP.NET MVC 1.0 ausprobiert

Keine Zeit? Hier die Kurzversion in 30 Sekunden.
- ASP.NET MVC 1.0 ist seit März da und läuft mit .NET 3.5 und Visual Studio 2008.
- Es gibt kein ViewState und keine Postbacks, dafür saubere URLs und volle Kontrolle über das HTML.
- Controller-Actions liefern ein ActionResult, Views sind einfache aspx-Seiten.
- Das Routing wird in der Global.asax festgelegt.
Seit ein paar Wochen ist ASP.NET MVC 1.0 fertig, und ich habe endlich Zeit gefunden, mich damit zu beschäftigen. Als PHP-Entwickler, der nebenbei C# macht, fand ich die Idee sofort sympathisch: Das Muster Model-View-Controller kennt man aus diversen PHP-Frameworks, jetzt gibt es das auch von Microsoft.
Was anders ist als bei WebForms
Vorweg: Ich habe mir MVC mit Visual Studio 2008 und .NET 3.5 angeschaut, ein neues Projekt lässt sich direkt über die Vorlage anlegen. Das Grundgerüst mit Home- und Account-Controller ist schon dabei, da kann man gut mal reinschauen.
Bei WebForms bekommt man Server-Controls, Postbacks und den ViewState. Das ist bequem, bis man genau wissen will, welches HTML am Ende rauskommt. Dann kämpft man gegen lange IDs und ein riesiges verstecktes Feld.
MVC macht das anders: Es gibt keine Controls mit Eigenleben. Eine URL wird auf eine Methode eines Controllers abgebildet, die holt Daten und gibt sie an eine View. Fertig. Gerade für Formulare ist das ungewohnt, weil man die Werte selbst aus dem Request holt und das Zustandsmodell von WebForms nicht mehr da ist. Das HTML schreibt man selbst, und es fühlt sich ein bisschen mehr nach PHP an.
Routing
In der Global.asax steht, wie URLs auf Controller und Actions abgebildet werden. Die Standardvorlage sieht so aus:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
}Die Platzhalter in geschweiften Klammern werden aus der URL gefüllt, und was fehlt, wird durch den Standardwert ersetzt. Ein Aufruf von /Produkte/Index landet also in der Methode Index des ProdukteController.
Controller und View
Ein kleiner Controller:
using System.Collections.Generic;
using System.Web.Mvc;
public class ProdukteController : Controller
{
public ActionResult Index()
{
var produkte = new List<string> { "Tastatur", "Maus", "Monitor" };
ViewData["Titel"] = "Unsere Produkte";
return View(produkte);
}
}Und die passende View unter Views/Produkte/Index.aspx:
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<List<string>>" %>
<html>
<body>
<h1><%= Html.Encode(ViewData["Titel"]) %></h1>
<ul>
<% foreach (var p in Model) { %>
<li><%= Html.Encode(p) %></li>
<% } %>
</ul>
</body>
</html>Das Html.Encode sollte man nicht vergessen, sonst ist man bei XSS ganz schnell dabei. Das nimmt einem das Framework hier nicht automatisch ab.
Mein erster Eindruck
Mir gefällt, dass man das Gefühl hat, wieder am Web zu arbeiten und nicht an einer Abstraktion davon. Der Code in den Views ist allerdings etwas gewöhnungsbedürftig, die vielen <% %> erinnern mich an PHP-Spaghetti. Man muss also diszipliniert bleiben und Logik im Controller lassen. Positiv fällt auf, dass sich die Controller prinzipiell auch ohne Webserver testen lassen, weil sie ganz normale Klassen sind. Das habe ich noch nicht richtig ausprobiert, es klingt aber vielversprechend.
Wer von WebForms kommt, braucht sicher etwas Umgewöhnung, weil die gewohnten Controls fehlen. Hat jemand von euch schon ein größeres Projekt damit gebaut? Ich bin gespannt auf eure Erfahrungen!
Beitragsbild: eigene Collage mit Logos von Wikimedia Commons (ASP.NET-Logo: Microsoft), jeweils gemeinfrei; die Marken gehören ihren Inhabern.
Christian Ackermann
Softwareentwickler (C++, C, Java, C#) aus der Oberpfalz, bloggt seit 2001 über Linux, Technik und Kochen.