Ich erinnere mich noch an meine erste Reaktion, als mir der geschätzte (damalige) Kollege Buberl seinerzeit ein bisschen Code von ASP.NET 1.0 zeigte, das muss Ende 2001 oder Anfang 2002 gewesen sein: "Wer will denn bitte so viel Kontrolle über seinen HTML-Code aus der Hand geben?". Das wird wohl vielen Leuten so gegangen sein, die damals mit ASP oder PHP arbeiteten.
ELMAH steht für Error Logging Modules and Handlers und ist kurz gesagt ein Plugin für ASP.NET-Anwendungen, mit dem Fehler, sprich Exceptions, geloggt werden können. Das Schöne daran ist, dass es sich ohne große Zeremonie installieren und sofort nutzen lässt, gleichzeitig aber auch konfigurier- und erweiterbar bleibt.
Schon bei ASP.NET MVC 1.0 (mein Gott, ist das wirklisch schon wieder zwei Jahre her?) gab es über das HandleError-Attribut eine gute Möglichkeit Fehlerseiten zu konfigurieren. Seit ASP.NET MVC 2 ist das gar nicht mehr nötig, es sei denn man möchte die Ausgabe wie im verlinkten Beispiel nach verschienenen Exceptions variieren.
Analog zum Beispiel mit dem Login-Check sollte man auch bei allen anderen Fehlern, die bei Ajax-Aufrufen passieren, den Benutzer nicht im Regen stehen lassen. Im klassischen Fall eines GET- oder POST-Aufrufs erhält man ja schließlich auch eine Fehlermeldung (mal mehr und mal weniger schön und vielsagend), das sollte auch für Ajax-Aufrufe gelten, bei denen Fehler ansonsten "verschluckt" werden.
Das Konzept der FormsAuthentication, welches bereits mit ASP.NET 1.0 anno 2002 eingeführt wurde, hat auch in ASP.NET MVC Bestand (auch wenn man auf Membership-, Profile-Provider und das andere Gedöns heute getrost verzichten kann/sollte). Es wurde ganz elegant übernommen, in dem man die Authentifizierungs-Prüfung über Attribute jeweils auf Action- oder Controller-Ebene regeln kann.
Ein immer wiederkehrendes Szenario bei Webapplikationen ist naturgemäß das Posten von Text(-Nachrichten) über Formulare und das Ausgeben dieser Texte, sei es in Foren, auf Profilseiten oder was auch immer. Da der Mensch bequem ist, setzt man ihm für seine Formatierungen einen WYSIWYG-Editor vor die Nase (z.B. CKEditor, sehr zu empfehlen), über den er ganz bequem seine Formatierungen für seinen Text vornehmen kann.
Ich muss zugeben: das hat mich ganz schön fuchsig gemacht. ASP.NET MVC 3 RC2 war installiert, alle Web.config-Einträge von Hand nach Vorlage eines Demoprojektes aktualisiert und die gut 90 Views im Projekt von Hand von .aspx/.ascx auf .cshtml und damit von der WebForms- zur Razor-ViewEngine umgestellt.
Wenn man mit der WebForms-ViewEngine arbeitet, ist die Sache relativ klar: ganze Seiten bekommen eine .aspx-View, Teile, also so genannte "Partials", bekommen eine .ascx-View. Der Unterschied, der auch historisch bedingt aus der WebForms-Ecke kommt: einem .ascx kann man keine Masterpage zuweisen, es enthält immer nur Teile einer fertigen HTML-Datei. Damit war die Sache hier erledigt.
Kleiner Schock nach der Umstellung vorhandenen Codes von MVC 1 oder 2 auf MVC 3: der in eigenen Extension-Methods generierte HTML-Code wird plötzlich in der Website lesbar dargestellt. Was passiert da?
Ich habe es mir angewöhnt bestimmte in den Views immer wiederkehrende Sachen in entsprechende Basisklassen zu packen, über die ich dann einen einfache und typisierten Zugriff darauf bekomme - als Beispiel wäre der angemeldete Benutzer zu nennen.
