Laden...

ASP.Net MVC (2) Verständniss der Sichtbarkeit

Erstellt von Kaji vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.489 Views
K
Kaji Themenstarter:in
593 Beiträge seit 2007
vor 13 Jahren
ASP.Net MVC (2) Verständniss der Sichtbarkeit

Hallo Community! 😃

Wie schon im letzten Thread bin ich noch dabei und finde es langsam sehr komisch. Ich bin aktuell auf dieser Seite. Ich finde es schon komisch das ein ViewModel dort hinzugefügt wurde, weil ich dachte der Controller macht die Sachen die dort das ViewModel macht? Also die Aufbereitung in Listen etc.. Naja hab ich mir noch nicht ganz soviel gedacht und erstmal weiter gemacht.

Als nächstes wurde dann im ViewModel das Model direkt referenziert. Hmm dachte ich ist der Controller jetzt komplett überflüssig? Klingt ja schon fast wie MVVM.

Ganz den Vogel hat es mir aber an folgender Stelle abeschossen:


<asp:Content  ID="Content2" ContentPlaceHolderID="MainContent"  runat="server">
 
    <h2>Browsing Genre: <%: Model.Genre.Name %></h2>
 
    <ul>
 
    <% foreach (var album in Model.Albums) { %>
        <li><%: album.Title %></li>
    <% } %>
 
    </ul>
</asp:Content>

Das ist ein Ausschnitt aus dem View. Das ViewModel ist verlinkt. Ok das Model.Albums kommt aus dem ViewModel blöde benennung aber naja. Aber der Typ von Model.Albums kommt aus dem Model direkt, das ist mir aufgefallen als ich das var durch den richtigen Typ ersetzen wollte und dabei kommt "MvcMusicStore.Models.Album" raus. Und das kann doch nicht sein oder? Ich meine damit greift das View doch direkt auf das Model zu auch wenns nur ne Typ deklaration ist?

Also ich weiß nicht mir kommen diese 3 Sachen komisch vor und hatte eigentlich ein wenig anderst über ASP.Net MVC (2) gedacht. Kann mir jemand vielleicht Licht in das ganze bringen? Bin ich ein wenig zu blöd und hab nen falsches verständniss?

Viele Grüße,

Kaji

G
497 Beiträge seit 2006
vor 13 Jahren

Die View soll die Daten aus dem Model darstellen. Wie sollte sie das denn machen, ohne eine Model-Instanz direkt anzusprechen?

Das ViewModel ist zu genau diesem Zweck da - Daten für eine View aufbereiten. Das ViewModel enthält dann alles, was die View braucht. Das soll verhindern, daß man in einer View auf einmal auf die Idee kommt, wieder Daten von anderen Quellen abzurufen. Ginge ja prinzipiell auch, ich kann da ja beliebigen Code ausführen. Der Controller bereitet die Daten in Form des ViewModels auf und übergibt sie an die View. Damit sind Datenaufbereitung und Präsentation voneinander getrennt.

K
Kaji Themenstarter:in
593 Beiträge seit 2007
vor 13 Jahren

Hallo GarlandGreene,

hmm das wird mir nicht ganz ersichtlich. Ich bin der Meinung gewesen das das Model die Daten in form von einer Datenbank oder was auch immer bekommt. Dann bekommt der Controller die Daten um sie aufzubereiten in Form von Bindings oder sonst was und dann werden diese Sachen ans Form gebunden. Dazu muss das Form nicht wissen das es ein Model gibt.

Ich dachte immer es geht diesen Weg Model->Controller->View und View->Controller->Model und nie View->Model.

Dachte eigentlich auch das es ein Sinn der Schichten ist das sie so abstrahiert werden. Ich meine wenn das View auf daten des Models und des Controllers zugreift ist das doch das reine Mischmasch.

Und warum brauche ich jetzt bei MVC das ViewModel? Ich meine hier bereiten doch Controller und ViewModel auf? oO

Viele Grüße,

Kaji

S
72 Beiträge seit 2009
vor 13 Jahren

Hallo Kaji,

ich bin auch gerade dabei mich mit MVC (2) zu beschäftigen.
Meiner Erkentniss/Meinung nach ist das ViewModel lediglich eine Aggregierung um die Darstellung von "mehr" als einer Model-Klasse zu realisieren. Oder ist es möglich einer View mehrere Typen von Model beizubringen? Schätze nicht, dann müsste es ja eine Models Collection innerhalb der View geben.

Ich dachte immer es geht diesen Weg Model->Controller->View und View->Controller->Model und nie View->Model.

Es geht auch der Weg View -> Model bzw. Model -> View, wobei zu beachten ist das jegliche Model-Klassen Aktualisierng über den Controller läuft.
Der View muss ja wissen "was" für Daten er darzustellen hat. Das Model wiederum kann dem View mitteilen: "Hey. Ich habe mich geändert. Bitte aktualisiere dich."

MfG
Stefan O.

P
67 Beiträge seit 2007
vor 13 Jahren

Hi Kaji,

vielleicht ist der Einstieg auf der Seite, die weiter oben genannt hast, nicht ganz geeignet, um das Verständnis für MVC zu bekommen. Ich würde dir raten erst ein mal das Grundverständnis von MVC anzuschauen. Dann kannst du direkt in die Programmierung auf der Seite einsteigen.

Wikipedia bietet hier eine sehr gute Übersicht für MVC (Link)

Gruß Phoenix

K
Kaji Themenstarter:in
593 Beiträge seit 2007
vor 13 Jahren

Hallo Phönix,

ich kenne die Seite und bin mir durchaus bewusst was dort steht. Und gerade deswegen stört mich z.b. dieser Absatz:

Auch für die Formatierung der Rohdaten und die Internationalisierung ist nicht definiert, wo diese erfolgen. Aus Gründen der Entwicklungs-Effizienz bietet es sich oft an, diese im Model zu integrieren, so dass man sich beim View auf die Erstellung von Widgets oder Templates beschränken kann. Andererseits werden dadurch Aspekte der Darstellung in das Model verlagert, was zur Grundidee durchaus im Widerspruch steht. Als Variante bietet es sich daher auch an, hierfür eigenständige Funktionsbereiche vorzusehen, die man dann weder Model, View oder Controller zurechnen muss.

Was für mich sprechen würde das das View eigentlich nicht direkt aufs Model zugreifen muss bzw soll.

Leider ist das alles ein wenig offen. Die Aufbereitung/Formatierung der Rohdaten könnte man, wie es auch angedacht ist, in ein ViewModel packen, nur würde ich dann nicht wie im Tutorial vom View übers ViewModel und dann aufs Model zugreifen. Den ich dachte eine strickte Trennung ist genau der Sinn der Sache. Den ich würde die Aufbereitung der Rohdaten fürs View komplett im ViewModel machen lassen, sodass der View keine Referenz aufs Model brauch. Das wäre an und für sich eine weitere Abstraktion.

Somit wäre der Controller davon auch komplett befreit und kann sich reinweg um die Validierung kümmern und das Model rein um die Logik und die Rohdaten.

Ist daran irgendwas verkehrt? Bin ich der einzigste dem es irgendwie nicht so gefällt das trotz ViewModel aufs Model direkt zugegriffen wird?

Viele Grüße,

Kaji

P
67 Beiträge seit 2007
vor 13 Jahren

Hi Kaji,

ja das ganze Thema ist manchmal etwas verwirrend. Ich muss dir ehrlich sagen, dass ich nicht sehr gerne mit MVC arbeite, da ich den Unterschied zwischen Controller und View nicht wirklich verstehen kann. Ich reduziere das meistens auf Model und View. Dabei ist die View nur für Darstellung und Benutzerinteraktion zuständig. Das heißt die ganze Verarbeitung der Daten wird komplett im Model gemacht. Die View startet damit nur den Vorgang und holt sich am Ende die Daten ab und stellt sie nur noch da.

Im Bereich ASP.NET wollte ich auch in die Richtung MVC gehen, aber da ich damit nicht wirklich besser zurecht kann, hab ich das ganze wieder auf eine ASPX Seite (View) mit Codebehind (Model) reduziert.

Was ich damit sagen wollte ist, dass du nicht nach einer exakten Grenze zwischen Model, View und Controller bzw. der genauen Definition des MVC suchen darfst. Es gibt da gewisse Bereiche, die je nach Anwendung und Verständnis des Programmierers etwas abweichen. Lese dich viel in solche Sachen ein und du wirst deine eigene Variante entdecken.

Gruß Phoenix

K
Kaji Themenstarter:in
593 Beiträge seit 2007
vor 13 Jahren

Hallo Phönix,

naja eigentlich finde ich das ganz gut, man muss es nur konsequent machen. Ich finde auch der Controller hat durchaus seine berechtigung um z.b. eingaben zu Validieren. Z.b. ob bei Datum wirklich ein valides Dateum eingegeben wurde. Das geht doch ganz gut.

Meine Vorstellung ist mittlerweile das der Weg folgend geht:

Client sendet eine Anfrage -> Daten kommen aus dem Model -> werden im ViewModel aufbereitet -> Wird im View angeziegt.

Und anderstrum:

Client macht eingaben im View -> Controller validiert die eingaben -> Wahlweise

  1. Die Eingabe ist nicht valide -> meldung ans Model der die Logik hat -> ViewModel nimmt die neuen Daten vom Model -> Die Daten vom ViewModel werden übers View angezeigt

  2. Die Eingabe ist valide -> meldung ans Model der die Logik hat -> ViewModel nimmt die neuen Daten vom Model -> Die Daten vom ViewModel werden übers View angezeigt

Das ist zwar an und für sich ein recht langer weg, aber ansonsten sehe ich das referenzen vom Controller ans ViewModel oder so müsste, und das ist ja eigentlich auch nicht nötig.

Gibt es vielleicht jemanden der ASP.Net MVC aktiv einsetzt und vielleicht ein paar Wörter dazu schreiben kann? Sind meine Gedanken komplett murks und muss es anderst angehen gedanklich?

Viele Grüße,

Kaji

S
72 Beiträge seit 2009
vor 13 Jahren

Hallo Kaji,

gehört die Validierung zum Controller oder zum Model? Meiner Meinung nach zum Model (was nicht bedeutet das es IN diesem Implementiert sein muss).

Auch kann ich dir noch das Tutorial (NerdDinner) aus diesem Thread ASP.NET MVC 1, Beispiele in Visual Stuio 2010 empfehlen. Bin auch gerade dabei dieses durchzuarbeiten.