.NET GUI

Hi,

ich arbeite aktuell an einem Projekt bei dem wir ASP.Net mit dem MVC Pattern einsetzen wollen/sollen. Ich habe dazu auch schon einiges an Information gefunden z.B.:  hier  . Mich würde aberinteressieren ob jemand bereits praktische Erfahrungen mit der auf ScottGu's Blog beschriebenen Microsoft Umsetzung gemacht hat.
...vorallem wäre interessant zu wissen ob jemand das ganze in Kombination mit Ajax einsetzt.

Danke und LG
Edmund

Hallo Edmund,

ich denke fundierte praktische Erfahrungen sind momentan noch sehr rar. Robert Mühsig beschäftigt sich sehr mit dem Thema. In seinem Blog wirst du viele Beiträge dazu finden.

Ich wäre vorsichtig damit, dass jetzt schon produktiv einzusetzen. Mal davon abgesehen dass es lizenztechnisch sicher noch nicht möglich ist (ich kenne doch MS ...), ist das Projekt, sofern ich Roberts Blog verfolge, noch in einem Status, in dem sich ne Menge ändert/noch ändern kann.

Was bewegt euch eigentlich, MVC einzusetzen? 

Hallo,

@Kai: Danke für den Link, kannte ich noch nicht

 

Thomas Bandt:

Ich wäre vorsichtig damit, dass jetzt schon produktiv einzusetzen. Mal davon abgesehen dass es lizenztechnisch sicher noch nicht möglich ist (ich kenne doch MS ...), ist das Projekt, sofern ich Roberts Blog verfolge, noch in einem Status, in dem sich ne Menge ändert/noch ändern kann.

Was bewegt euch eigentlich, MVC einzusetzen? 

Aus lizenztechnischer Sicht habe ich das ganze noch gar nicht betrachtet, aber sollte uns nicht treffen da wir leider nicht auf eine Releaseversion warten können und deshalb gezwungen waren/sind eine eigene Implementierung (eng an der Microsoft Lösung) umzusetzen. Wir verwenden da jetzt keine Klassen aus der MS Version gehen aber bei Requestprocessing und Routing den selben weg wie MS d.h. HTTP Modul das die URL parsed und interpretiert und über einen HttpHandler PRoxy (unsere Controller Implementierung ) an die View (WebPage ) zur Darstellung weitergibt.

MVC ist für uns deshalb Thema, weil wir das Projekt als quasi Minni Framework für unsere Firma entwickeln und wir deswegen auf jeden Fall eine strikte Trennung von Logik und Darstellung vorgeben und durchsetzen wollen. Mit MVC sollte es uns gelingen, die Darstellung komplett zu entkoppeln und durch z.b. Flash oder Winforms oder was auch immer kommen mag erledigen zu lassen.

...Unser Projekt soll im Herbst Life gehen

 

Danke und LG

Edmund

hmm... nachdem ich mir die Videos von Scott Hanselman angesehen habe, werde ich MVC warscheinlich nicht einsetzen. Zumindest sehen ich keine klaren Vorteile gegenüber herkömmlichen, sauber entwickelten ASP.NET Anwendungen. Im Gegenteil: Ich sehe in den Videos, dass das herkömmliche vorgehen bei ASP.NET Anwendungen komplett über den Haufen geworfen wird. Es wird zwar die Logik vom View getrennt, aber Code und Design mischen sich wieder. Das wird auch in einigen Beispielen (hier und hier) von Robert Mühsig sichtbar.

Ich würde auf die Vorteile vom ASP.NET (Trennung Code und Design) nicht verzichten wollen... ;-)

Da ich hier schon verlinkt bin, möchte ich natürlich auch mal meine Erfahrungen abgeben.

Erstmal als Einstieg ein paar Worte über mich: Ich komme aus der PHP Ecke (düstere und finstere Zeit) und hab dort mit purem HTML/Javascript gearbeitet. Das heisst ich wusste genau, was ich gerendert wird, wie der Ablauf ist und das da keine große Magie dahinter steckt.

Dann hab ich mir ASP.NET angeschaut und war erst positiv Überrascht, was es da nicht so alles schönes gibt. Mit der Windows Client Entwicklung hatte ich weniger am Hut, aber ASP.NET WebForms erinnert stark an WinForms - das leuchtete mir ein. Allerdings (wie die Natur von HTTP so ist) gibt es unterschiede die mich immer wieder gestört hatten.

Ich hatte angenommen ein Button - der hat dann eine Funktion aufgerufen und mir eine Tabelle erstellt wo in der letzten Spalte wieder ein "Löschen" und "Bearbeiten" Button war. Diese hab ich dynamisch erstellt und mit entsprechenden Eventhandlern versehen. Jetzt hatte ich allerdings das Problem: Sobald ich auf den Bearbeiten Knopf gedrückt hatte, wurde das Event nicht geworfen (weil es nicht im PageLoad erzeugt wurde bzw. ASP.NET nicht bekannt war). Ich denke dass ich hier nur irgendeinen dummen Fehler gemacht hatte und das sicherlich recht einfach umzusetzen geht, aber was mich daran stört ist folgendes: ASP.NET WebForms suggeriert mir, dass ich sowas "wie in der Desktop-Welt" umsetzen kann. Das haut aber nicht immer ganz hin. Auch der HTML Quellcode ist fürchterlich. Wenn man mit coolen Javascript Sachen nun auf irgendwas zugreifen möchte, muss man es entweder umständlich über irgendwelchen ScriptManager etc. machen oder man bastelt etwas rum. Ich bin einfach nicht mit diesem System klar gekommen - ich hab mir auch dutzende Webcasts etc. angesehen, aber ViewState/PageLifecycle/Postbacks etc. find ich einfach unsexy ;)

HTML ist so einfach - warum muss denn alles immer in einer "<form..." sein? So wurde HTML nicht gedacht.

Und jetzt kommt das MVC Framework: Für mich ist es einfach absolut fantastisch. Man hat vollständige kontrolle über das was am Ende gerendert wird. Es ist zudem nicht wahr, dass Code/Design wieder miteinander verschwimmt - die Views stellen nur ein Template dar. Code (z.B. DB Abfragen) haben dort nichts zu suchen. Durch das MVC Modell kann man sehr gut Trennen. Auch im Team kann ich mir das gut vorstellen, da sich jemand angenommen nur um das Modell kümmert, der andere macht die Controller und ein dritter kann exclusiv am View rumschrauben. Genau sowas bräuchte ich auch bei einem aktuellen Projekt. 

Ich (und auch die Microsofties) glauben nicht, dass dieses Modell allen gefallen wird, aber es hat Vorzüge: Komplette Kontrolle über den HTML Quellcode, Aufsplittung durch MVC, alles ist erweiter oder austauschbar (Z.B. eine XSLT Viewengine anstatt Webforms) und testbar. Einige Sachen gehen sicherlich auch mit "normalen" ASP.NET, aber wie viele Hacks braucht man in ASP.NET bis man eine ganz saubere XHTML Seite hat. Diese "eingebauten" Controls haben meist einen hässlichen Output und um das zu beeinflussen bedarf es einige Mittel - es gibt einen ASP.NET CSS Friendly Adapter etc.

Es ist eine Alternative (die in meinen Augen) ideal für Leute die PHP/JSP/Ruby können und wissen wollen, was da an HTML gerendert wird. Bei einem View gehört nunmal auch die Daten rein - dieses templateartige find ich schonmal sehr sexy :)

Edit: Und zur eigentlichen Frage - ASP.NET AJAX ist zwar möglich - aber man ich glaube eine Alternative JS Bibliothek wie z.B. jQuery ist in diesem Fall besser (und ist auch unheimlich mächtig). Mit der AJAX Sache und MVC beschäftige ich mich demnächst. Ich hoff ich kann auch AJAX Requests an die Controller abgeben - wenn das geht, ist es recht einfach damit zu Arbeiten.

Vorweg - ich beobachte das Ganze durchaus interessiert und bin nicht komplett dagegen, aber ich picke mir aus Zeitgründen erstmal nur das raus, was ich für nicht so ganz richtig halte ;-).

Robert.Muehsig:

Man hat vollständige kontrolle über das was am Ende gerendert wird. Es ist zudem nicht wahr, dass Code/Design wieder miteinander verschwimmt - die Views stellen nur ein Template dar.

Nimm mal dein Pager-Beispiel, und versuche einem Designer, der nur HTML und CSS kann, klar zu machen wie das funktioniert und was er da tun muss. Mit WebForms kann er deklarativ arbeiten, sich das Ganze über Templates der Controls und IntelliSense intuitiv selbst erarbeiten - das geht nicht, wenn man da selbst "drin rum scriptet". 

 

Robert.Muehsig:

Code (z.B. DB Abfragen) haben dort nichts zu suchen. Durch das MVC Modell kann man sehr gut Trennen. Auch im Team kann ich mir das gut vorstellen, da sich jemand angenommen nur um das Modell kümmert, der andere macht die Controller und ein dritter kann exclusiv am View rumschrauben. Genau sowas bräuchte ich auch bei einem aktuellen Projekt. 

Die Trennung bekommst du auch mit WebForms hin - .aspx/.ascx für den Designer, CodeBeside und alles was dahinter steckt für den Entwickler. Die Trennung ist hier bei entsprechender Arbeitsweise genauso sauber, vor allem wenn man darauf verzichtet Logik in CodeBeside/CodeBehind zu haben.

 

Robert.Muehsig:

Einige Sachen gehen sicherlich auch mit "normalen" ASP.NET, aber wie viele Hacks braucht man in ASP.NET bis man eine ganz saubere XHTML Seite hat. Diese "eingebauten" Controls haben meist einen hässlichen Output und um das zu beeinflussen bedarf es einige Mittel - es gibt einen ASP.NET CSS Friendly Adapter etc.

 

Also Hacks braucht es seit ASP.NET 2.0 überhaupt keine mehr, um valides XHTML rauszubekommen. Die Zeiten in denen ich einen schön formatierten HTML-Output generiert hab sind vorbei - ich konzentriere mich lieber auf das Wesentliche, und das ist das was der User im Browser sieht und das was dahinter am Server abläuft, nicht das was man bei Rechter Maustaste > Quelltext anzeigen bekommt. Das interessiert keinen Menschen. 

Just my 2 cents.

Also zum Thema: Designer arbeiten an Templates: Das man einem Designer eine ASPX/ASCX oder ein X-beliebigen MVC View geben kann (ist jedenfalls bei uns) kaum der Fall. Die haben ihr Fotoshop im Griff und dann gibts noch HTML Templates - die ich dann entsprechend in dynamische Controls umbauen muss. Vor allem weil wir ein Haus sind, was viel JSP etc. macht kennen die Designer nichts anderes.
Ich bekomm am Ende ein fertiges CSS Layout was richtig schick aussieht - und jetzt kommen die ASP Controls ins Spiel die nicht immer so wollen, wie ich das will - dazu noch dieses seltsame Postbackverhalten was mir nicht ganz einleuchtet (siehe die Geschichte von oben) und schon ist mein Frust geboren ;)

Auch in dem offiziellen MVC Forum gab es bereits mehrere Diskussionen, warum man wieder zurück auf Inline Code geht und auch wieder stateless wird - ohne postbacks etc.. Ich denke dies ist Geschmackssache und hat auch viel mit der Vorgeschichte zu tun. Wenn man aus der PHP etc. Welt kommt, dann ist WebForms Modell recht seltsam - wenn man aber mit ASP.NET oder WindowsForms aufgewachsen ist, weiß man es zu schätzen :)

Aus meiner Sicht ist das MVC aber auch auf mehrere Weise interessant:
Die Entwicklung die hier Microsoft einschlägt ist äußerst positiv. Die "neuen" im ASP.NET Team scheinen frischen Wind mitgebracht zu haben - (mehr oder weniger regelmäßige) Builds/Source Code auf Codeplex, sehr viel kann geändert werden durch die vielen Schnittstellen (ViewEngines, Routing...), die coolen "ActionFilter" - was eine Art HttpFilter ist - nur eine Stufe höher und nicht ganz so nah an den Basics - MVC, Unittest sind einfacher etc.. Generell ist (denke ich) MVC die Zurückbesinnung auf das eigentlich recht einfache HTTP - ohne Postbacks, Pagelifecycle etc.

Das sind "Vorzüge" von MVC - die sicherlich auch teilweise (oder auch voll) mit WebForms darstellbar sind. Aber was man nicht vergessen sollte: MVC ist nur eine Alternative - kein neues "WebForms".

Das es am Ende nie jemanden interessiert, wie der Quellcode aussieht ist richtig - aber bei den Heutigen AJAX/"Web 2.0"/Javascript Anwendungen gefällt mir vollge Kontrolle doch recht gut.

Ein kleines Beispiel nochmal wo ich dachte, dass sowas doch recht einfach ist:
Eine Masterpage und eine Contentpage mit einem Logincontrol, was man über ein Template gestaltet hat (@Thomas: Der Blogpost von dir dazu war klasse :) ). Jetzt wollte ich recht einfach nur das die Form bei einem "Enter" abgeschickt wird. Dazu muss ich mir erst die Form im Codebehind von der Masterpage schnappen und den Default Button auf den Login Button setzen. Da kam wieder meine Frage im Kopf auf: Warum so kompliziert? In PHP (oder puren HTML) ist das so einfach und ohne "Hacks" machbar (ja - sowas empfinde ich als Hack ;))

Hallo zusammen,

Robert.Muehsig:

Wenn man aus der PHP etc. Welt kommt, dann ist WebForms Modell recht seltsam - wenn man aber mit ASP.NET oder WindowsForms aufgewachsen ist, weiß man es zu schätzen :)

ich habe früher ebenfalls PHP und sehr viel classic ASP gemacht. Als ich zum ersten Mal mit Webforms gearbeitet habe, stellte sich bei mir tatsächlich eine Art "Wow-Effekt" ein. Vieles was ich früher mühsam per Hand machen musste, geht nun viel leichter von der Hand. Natürlich gibt es hier und da ebenfalls Uwegbarkeiten, die nun durch Umwege gelöst werden müssen.

Aber ganz auf Webforms verzichten möchte ich nicht. Ich bin jedoch trotzdem wirklich daran interessiert wie sich MVC weiterentwicklt.

Robert.Muehsig:

Ein kleines Beispiel nochmal wo ich dachte, dass sowas doch recht einfach ist:
Eine Masterpage und eine Contentpage mit einem Logincontrol, was man über ein Template gestaltet hat (@Thomas: Der Blogpost von dir dazu war klasse :) ). Jetzt wollte ich recht einfach nur das die Form bei einem "Enter" abgeschickt wird. Dazu muss ich mir erst die Form im Codebehind von der Masterpage schnappen und den Default Button auf den Login Button setzen. Da kam wieder meine Frage im Kopf auf: Warum so kompliziert? In PHP (oder puren HTML) ist das so einfach und ohne "Hacks" machbar (ja - sowas empfinde ich als Hack ;))

Wenn ich mich nicht täusche ist das auch ganz einfach und ohne Programmierung im Codebehind möglich. Einfach die Eigenschaft "DefaultButton" des Panel-Controls verwenden. Aber auch in diesem Fall muss man es natürlich wissen...

Mahlzeit,

Robert.Muehsig:

Also zum Thema: Designer arbeiten an Templates: Das man einem Designer eine ASPX/ASCX oder ein X-beliebigen MVC View geben kann (ist jedenfalls bei uns) kaum der Fall. Die haben ihr Fotoshop im Griff und dann gibts noch HTML Templates - die ich dann entsprechend in dynamische Controls umbauen muss.

das ist meiner Erfahrung nach eher ineffizient, weil schon bei der kleinsten Änderung wieder aufwändige Abstimmung notwendig wird. Wenn der Designer die Templates direkt umsetzt, gestaltet sich das viel leichter, ein <asp:Panel /> ist ja auch nichts anderes als ein <div /> für den Pixelschubser ;-). Siehe den anderen aktuellen Thread zum Thema Usability-Entwicklungsprozess.

Und wenn dann die Situation da ist dass es eben so läuft, dass der Designer direkt dran arbeitet, dann wirft dich das Inline-Gescripte wieder zurück.

Robert.Muehsig:

Auch in dem offiziellen MVC Forum gab es bereits mehrere Diskussionen, warum man wieder zurück auf Inline Code geht und auch wieder stateless wird - ohne postbacks etc.. Ich denke dies ist Geschmackssache und hat auch viel mit der Vorgeschichte zu tun. Wenn man aus der PHP etc. Welt kommt, dann ist WebForms Modell recht seltsam - wenn man aber mit ASP.NET oder WindowsForms aufgewachsen ist, weiß man es zu schätzen :)

Da ist etwas dran, aber die Ursache liegt eher in der ziemlich steilen Lernkurve, die man mit ASP.NET WebForms hat. Meine Anfänge liegen in ein bisschen PHP, danach habe ich jahrelang ausschließlich mit Classic ASP gearbeitet - und hatte entsprechend meine Schwierigkeiten mich in ASP.NET zurecht zu finden. Ich glaube das erste Buch habe ich mir Ende 2002 gekauft, produktiv gearbeitet (und dabei grausamsten Code geschrieben) habe ich Mitte 2004.

Aber wenn man sich einmal durchgebissen und sich mit ViewState, Lifecycle & Co. arrangiert hat, sieht man schnell die Vorteile und will auf keinen Fall wieder zurück. 

Robert.Muehsig:

Aus meiner Sicht ist das MVC aber auch auf mehrere Weise interessant:
Die Entwicklung die hier Microsoft einschlägt ist äußerst positiv. Die "neuen" im ASP.NET Team scheinen frischen Wind mitgebracht zu haben - (mehr oder weniger regelmäßige) Builds/Source Code auf Codeplex, sehr viel kann geändert werden durch die vielen Schnittstellen (ViewEngines, Routing...), die coolen "ActionFilter" - was eine Art HttpFilter ist - nur eine Stufe höher und nicht ganz so nah an den Basics - MVC, Unittest sind einfacher etc.. Generell ist (denke ich) MVC die Zurückbesinnung auf das eigentlich recht einfache HTTP - ohne Postbacks, Pagelifecycle etc.

Für uns als Entwickler kann das erstmal nur von Vorteil sein, das ist richtig. Aber ich glaube der Grund liegt nicht darin, dass da wieder jemand "back to root" möchte, sondern eher an der Konkurrenzsituation, vor allem mit Ruby on Rails z.B. - das ist im Moment einfach hipp, da muss man als MS etwas entgegensetzen. Reine Politik.

Robert.Muehsig:

Das es am Ende nie jemanden interessiert, wie der Quellcode aussieht ist richtig - aber bei den Heutigen AJAX/"Web 2.0"/Javascript Anwendungen gefällt mir vollge Kontrolle doch recht gut.

Dito, aber in dem Moment wo du dich auf irgendein Framework einlässt, sei es nur ein Ajax-Framework kannst du das mit der Kontrolle schon wieder vergessen.

Robert.Muehsig:

Ein kleines Beispiel nochmal wo ich dachte, dass sowas doch recht einfach ist:
Eine Masterpage und eine Contentpage mit einem Logincontrol, was man über ein Template gestaltet hat (@Thomas: Der Blogpost von dir dazu war klasse :) ). Jetzt wollte ich recht einfach nur das die Form bei einem "Enter" abgeschickt wird. Dazu muss ich mir erst die Form im Codebehind von der Masterpage schnappen und den Default Button auf den Login Button setzen. Da kam wieder meine Frage im Kopf auf: Warum so kompliziert? In PHP (oder puren HTML) ist das so einfach und ohne "Hacks" machbar (ja - sowas empfinde ich als Hack ;))

 

Wie Kai schon schrieb, einfach ein Panel rein, DefaultButton-Eigenschaft setzen, fertig :). 

Ich seh es pragmantisch: Soll jeder das nehmen, womit er am besten zurecht kommt. Ich (und sicherlich der ein oder andere auch) ist glücklich mit MVC. Das es natürlich MS darum geht, Ruby und co. was entgegenzusetzen ist auch klar. Ich mag sogar den Inline Code - solange er nur zur Datenausgabe da ist. Denn nichts anderes sollte ein View sein. Das es hin und wieder natürlich if und else drin vorkommen müssen ist auch klar - aber ob ich das nun im Codebehinde hab oder direkt in meinem View wo man es nachvollziehen kann.

Wir haben hier in der Firma mehrere große JSP oder PHP Sachen - die Designer kommen damit mehr oder weniger klar. Einzige Ausnahme ist ganz klar unsere Microsoft Abteilung. Das ein <asp:Panel..> als <div> gerendert wird ist klar, aber die vielen kleinen Feinheiten sind schwierig und daher bekommen wir max. CSS und HTML geliefert. Wenn es jetzt an das Umsetzen geht, ist das aber manchmal etwas ungünstig. Als triviales Beispiel: Es ist nicht ganz so einfach ein ASP Element zu erzeugen was keine ClientID hat.

Allein schon anhand der Namen der Controls schließ ich mal darauf, dass es aus den "WinForms fürs Web" Gedanken entwickelt wurde. Meinem Verständnis aber nach ist die herangehensweise "falsch", weil Web und Desktop von Grund auf verschieden sind. Warum braucht jede Seite ein <form...> usw.

Wie anfangs erwähnt ist es sicherlich nicht für jeden geeignet - einfach weil man es als Rückschritt empfindet (wie in dem anderen Thread gesagt wurde ;) ).

Meiner Meinung nach sollte (wenn man sich nicht ganz sicher ist) es einfach mal ausprobieren. ASP.NET MVC ist kein "ASP Classic Version 2008" sondern eine andere herangehensweise - eine die PHP / JSP etc. ähnelt. Wenn man kein Inline Code mag kann man auch Controls erstellen, die genauso wie bei ASP.NET Webforms <aspmvc:Label Text="asds" Id="..." /> aussehen. Alles was kein Postback einsetz funktioniert nach wie vor - Scott Guthrie hat ein Beispiel mit einem Repeater in seinem Blogpost gezeigt. 

Die große Lernkurve bei ASP.NET ist sicherlich der Pagelifecycle - mit Postbacks, Viewstates etc. - genau dieser Teil gefällt mir nicht - warum so kompliziert. Man macht wieder normale Forms und hat am Ende einen Controller der mit den Daten rumhantiert, der rendert einen View auf dem mehrere UserControls sein können - der Lifecycle hier ist wesentlich "einfacher". Den Viewstate gibt es allerdings nicht - der ist aber manchmal ein Fluch und manchmal ein Segen - aber wer weiß was da noch kommt. MVC erlaubt ziemlich viel und ist erweiterbar bzw. sind die Komponent austauschbar. Man könnte den Viewstate sicherlich durch ActionFilter etc. nachempfinden. 
Was ich damit sagen möchte: Man sollte es testen - wem der <%=ViewData.Id%> Syntax nicht gefällt kann sich auch entsprechende Controls bauen.

Und wenn einem das immer noch nicht zusagt: Es ist ja nur eine Alternative :) 

 

Hallo zusammen

Interessante Diskussion. 

Robert.Muehsig:

Es ist nicht ganz so einfach ein ASP Element zu erzeugen was keine ClientID hat.

- http://www.aspnetzone.de/blogs/peterbucher/archive/2008/02/24/ein-webcontrol-das-keine-clientid-rendert.aspx

Damit kannst du ziemlich viel, und das auch einfach machen.
Bspw. alle ClientIDs per Default nicht Rendern (Ausser die von Form Elementen),
zudem jeweils Controls registrieren, dessen ClientID gerendert werden soll (Für clientseitige Zugriffe) :-)

Gruss Peter

Das mit der ClientID war eine Anspielung auf deinem Blogeintrag - zwar funktioniert das bestimmt wunderbar, aber ist es eigentlich für so eine triviale Sache nicht ziemlich komplex?
Ein netter Spruch aus dem MVC Forum:
"Simplicity - web applications shouldn't be rocket science!"

Versteht mich nicht falsch: Ich bin sicher das man mit WebForms sicherlich die gleichen Ergebnisse erreichen kann wie mit MVC- es ist halt nur eine andere Art, die den einen vielleicht mehr zusagt, den anderen eher weniger. :)

"Keep it simple..."

Hallo Robert

Aha, so rum :))

Naja, simpler gehts mit Webforms nicht mehr, und meine Idee (oben) lässt alles offen.
Aber klar, wenn nix da ist, ist auch nix (Keine Vorgabe bei MVC).
Eins ist aber klar... da man WebControls in MVC Views verwenden kann... die kein ViewState benötigen und nicht auf die PostBack Architektur aufbauen (Tun alle meine Controls nicht, ich mag das nicht ;-)... schon ne feine Sache.

Aber:
Was dürfen die Controls alles enthalten?
Wieviel und was für Logik?

Jetzt aus der MVC Perspektive und Gedanken gesehen....

Ganz abgesehen davon:
Lifecycle ist zwar ein minimaler vorhanden (durch das MVC Paradigma), aber der Lifecycle von der Masterpage und ViewPage + Controls ist ja immer noch vorhanden, ansonsten würden die ja nicht funktionieren.
Benutzt werden / müssen die Lifecycles von Master- und ViewPage aber nicht.... läuft halt alles automatisch ab.

Ich habs mir nicht sooo genau angeschaut, müsste IMHO aber so sein, oder täusch ich mich da? :-)

Gruss Peter

In einem View sollte (meiner Meinung nach) max. if / else Abfragelogik enthalten sein um je nach ViewData was anderes zu rendern. DB Abfragen oder komplexere Sachen sollten im Controller / Model bleiben.
Momentan gibt es aber noch keine richtigen "Controls" mit eigener Logik (im Sinne von eigener Controller + View) wie bei den WebForms - irgendwelche 3rd Party Controls sind daher momentan nicht herstellbar:

Der Controller schickt ViewDaten an einen View - dieser rendert dass und kann über eine spezielle Methode UserControls ebenfalls rendern - man gibt also vom Controller über den View die ViewDaten bis zum UserControl weiter.
Hier ist mein Paging User Control ein gutes Beispiel:
http://code-inside.de/blog/2008/04/08/aspnet-mvc-pagination-view-user-control/
Diese User Control hat (bis auf etwas if / else) keine Logik und auch keinen eigenen Controller.

Jetzt gibt es natürlich gewiss einige Controls die nicht unbedingt was mit dem View und dessen Daten zutun haben, aber trotzdem dynamische Daten rendern sollen, z.B. ein Ticker auf einer MasterPage. Die MasterPage hat momentan auch keinen eigenen Controller. Um solche Daten darzustellen gibt es momentan den "ComponentController". Diese "Componente" kann also eine eigene Logik (in dem ComponentController) und einen eigenen View haben. Siehe hier:
http://code-inside.de/blog/2008/04/15/aspnet-mvc-dynamische-daten-auf-der-master-page/

Dieser "ComponentController" ist allerdings nur ein Versuch gewesen - die Entwickler haben bereits im Forum angekündigt dass die Controller in den nächsten Releases erweitert werden. Das Thema Controls (wie man es bei WebForms kennt) ist auch gerade im offiziellen Forum aktuell und dort wird auch vermutet, dass hier sicherlich noch einige Sachen hinzukommen werden - insbesondere um die 3rd Party Control Hersteller einen Anhaltspunkt zu geben :)

Um es nochmal kurz zu sagen:
UserControls haben momentan keine eigene Logik (bis etwas if / else - hier kommt es natürlich auf den Entwickler an wie weit er es treibt) und beruhen auf den übergebenen Viewdaten - die Componenten (welche eigene Logik haben und sozusagen direkt auf einer Seite gesetzt werden können ohne mit den eigentlichen Viewdaten zutun zu haben) sind noch nicht in einem "stabilen" Status.

Zum Lifecycle:
Den gibt es natürlich noch - da die Default-Viewengine die WebForms Viewengine ist dürfte (ich hab das jetzt nicht nachgeschaut, sollte aber so sein) auch das PageLoad Event etc. geworfen werden. Er ist hier aber durch das weglassen von den Postbacks nicht mehr so "interessant" bzw. hab ich mir da jetzt noch keinen Kopf gemacht, weil durch das Zusammenspiel durch View und Controller der Datenfluss geregelt ist - ist halt so eine Art PingPong Spiel ;)