Laden...

MVC (Model-View-Controller Pattern mit ASP.NET)

Erstellt von wolfe vor 19 Jahren Letzter Beitrag vor 17 Jahren 19.987 Views
Information von herbivore vor 12 Jahren

Dies ist ein Thread, auf den aus der FAQ ([FAQ] Kommunikation von 2 Forms) verwiesen wird. Bitte keine weitere Diskussion, sondern nur wichtige Ergänzungen und diese bitte knapp und präzise. Vielen Dank!

W
wolfe Themenstarter:in
19 Beiträge seit 2004
vor 19 Jahren
MVC (Model-View-Controller Pattern mit ASP.NET)

Wir arbeiten an einem WebPrtojekt auf Basis von ISpyPortal. In letzter Zeit habe ich einiges über MVC gehört und hab mir mal das Maverick Projekt angesehen. Eigentlich habe ich mir mehr davon erhofft, wobei ich noch nicht hinter den tiefen Sinn gestiegen bin.
Ich hätte da mal ein paar Fragen:
Durch die Entkopplung der ASP.NET Seiten mit dem Pattern gehen doch die ganzen ROUNDTrips verloren, das heißt ich kann die Serversteuerelemente wenn überhaupt nur schwierig nutzen. Dies ist doch ein tolles Feature von ASP.NET. Genauso die serverseitige Eventbehandlung. Warum muss es denn immer so umständlich sein, wenn es doch auch einfacher geht.

Ist das MVC Pattern eigentlich nicht veraltet, da doch ASP.NET schon eine gewisse Architektur mit CodeBehind vorschreibt?

Wo liegt den der tiefe Sinn in den MVC-Patterns, ich glaube in der Praxis kann das nur sehr schwer umgesetzt werden?

Ich hab zwar schon einige Fachbeiträge dazu gelesen, doch so wirklich schlau bin ich nicht geworden.

P
939 Beiträge seit 2003
vor 19 Jahren

Ich hab den Eindruck du machst da etwas komplizierter als es ist. Ich versuche es mal zu erklären.

Das Ziel von MVC ist es, die Darstellung von der Anwendungslogik zu trennen. Der Vorteil ist, dass Model und View austauschbar werden. So kann eine ASP.NET-View beispielsweise durch eine WinForms-View ersetzt werden. Ein weiterer Vorteil ist, dass View und Model saubere Schnittstellen bekommen.

Im Model werden Anwendungsdaten und Anwendungslogik zusammengefasst. Es hat keine Referenzen auf View-Klassen. Es wartet passiv auf Steueraufrufe von aussen. Änderungen werden als Ereignisse nach aussen gegeben. Mit der View ist es das selbe - keine Referenzen aufs Model, nur passiv, Benutzer-Aktionen werden per Ereignis mitgeteilt. Model und View stehen also für sich alleine.

Zwischen Model und View sitzt der Controller, der sich für die Ereignisse registriert hat und das Zusammenspiel steuert. Änderungen der View oder Benutzeraktionen werden von ihm ins Model übertragen. Model-Änderungen, z.B. Berechnungen oder Datenbank-Abfragen, werden zurück in die View übertragen, gegebenenfalls wird die Ansicht gewechselt. Jede Aktion läuft über den Controller. Natürlich, Model-Daten, die 1:1 in der View angezeigt werden und umgekehrt, können direkt verknüpft werden. Das Herstellen der Verknüpfung bleibt aber Aufgabe des Controllers.

ASP.NET passt sehr gut in dieses Schema. View-Klassen sind die WebControls, Controller und Model sind eigener Anwendungscode. Man muss zwar mehr tippen, wenn's klappt, bekommt man dafür zwei Anwendungsteile - Core und GUI (ASP.NET) - und man kann leicht weitere GUIs anbinden - WinForms, PHP, neue ASP.NET-GUI ... Kommandozeile usw.

Gruss
Pulpapex

W
wolfe Themenstarter:in
19 Beiträge seit 2004
vor 19 Jahren

Hallo Pulpapex,
danke für Deine ausführliche Antwort. Ich denke ich werde mal in unsere Anwendung ein MVC versuchen einzuarbeiten.
Seither habe ich die Trennung der GUI und Anwenderlogik über Webservices realisiert. Das Funktioniert sehr gut, und ich bin dann im GUI auch unabhängig. Das heißt egal ob WinForms, ASP.NET GUI oder Java GUI funktioniert die Sache echt gut. Bei PHP weiß ich nicht Bescheid, müsste aber auch funktionieren. Meines erachtens sind die Webservices die Zukunft. Aber vielleicht mache ich da ja schon die Trennung ala MVC. Was ich bei Webservices noch nicht versucht habe sind asynchrone Aufrufe aber dies sollte ja auch funktionieren. Bei der Performance habe ich entgegen meinen Erwartungen keine großen Probleme festgestellt. Einzig die noch mangelhafte Datentypenunterstützung ist noch ein Problem, doch so weit ich weiß wird ja bereits über einen Standard diskutiert.

Gruß
Wolfe

P
939 Beiträge seit 2003
vor 19 Jahren

Vielleicht ist das hier noch ganz interessant:
User Interface Process (UIP)

Abstracting Navigation and Workflow Code

The workflow of an application is a business process, not a user interface process, and the control of it should lie outside of the user interface layer. Code abstraction also helps you to maintain and extend your existing applications more easily.

The UIP Application Block abstracts workflow code from the user interface layer into the user interface process layer. As the navigation within the workflow is not hard coded into the user interface elements themselves, if the flow of your application changes, you need to recode the process only, not the elements within the process.

Auf der Seite wird auch MVC erklärt. UIP basiert auf dem MVC-Pattern.

F
10.010 Beiträge seit 2004
vor 19 Jahren
R
1 Beiträge seit 2006
vor 17 Jahren
ASP.NET + Webfacade = MVC

Der Controller liefert die Daten an die Webfacade, wobei diese die Rolle als Model übernimmt. In ASP.NET gilt der Code-Behind einer Seite bereits als Controller, Das MVC-Pattern ist also sozusagen 'von Hause aus in ASP.NET implementiert'. Gemeinsame Controllerlogik (z.B. Listpage/Detailpage) können durchaus über eine Basepage mit gemeinsamem Basiscode 'verbunden' werden. Es ist - wie Du anfangs erwähnt hast - unsinnig, das tolle Control- und State-Handling zugunsten irgend einer pseudoprofessionellen Lösung abzukoppeln. Businessrelevante States gehören ins Dataset, technische States in den Application- resp. Sessionkontext oder andere Cachecontainer. Alles was stateless ist, kann deine Webfacade übernehmen oder Du baust Dir Helperklassen (oder realisiert das innerhalb der Basepage), wenn Du auch clientside Zugriff brauchst.

Viele Grüsse
Raoul

F
10.010 Beiträge seit 2004
vor 17 Jahren

Schon gesehen von wann der Thread war?

Inzwischen sind viele der Meinung das für ASP.NET eher MVP etwas ist.

Und wenn Du dann noch Ajax.net (ehemals Atlas) benutzt, ist etwas wie dynamsiche Seiten keine Hexerei mehr.

ASP.NET Ajax Under-the-hood Secrets