2009-06-20 5 views
4

Ich habe für ein paar Monate ASP.NET MVC gelernt. Ich habe gelernt über Ansichten und Controller und Modelle und so. Um eine Ansicht zu entwerfen, benötigen wir immer ein Modell. Normalerweise ist ein Modell nur eine Klasse, die wir mit Daten füllen und an eine Ansicht übergeben. Ich habe hier eine Frage: Sollte ein Modell selbst etwas berechnen, oder sollte es nur dumm sein?Sollte ein Modell selbst eine Berechnung durchführen?

Zum Beispiel habe ich eine Website, wo ich laden Book s von User s. Meine Modellklasse ist wie folgt:

public class FormViewModel 
{ 
    public User MyUser {get; set;} 
    public Books UserBooks {get; set;} 

    //Constructor here. 
    public FormViewModel(User _user, Books _userBooks) 
    { 
    this.MyUser=_user; 
    this.UserBooks=_userBooks; 
    } 
} 

Diese Klasse hat nichts tun - es ist nur eine Vorlage. Nun, wenn ich den Code wie folgt ändern:

public class FormViewModel 
{ 
    public User MyUser {get; set;} 
    public Books UserBooks {get; set;} 

    //Constructor here. 
    public FormViewModel(User _user) 
    { 
    this.MyUser=_user; 
    this.UserBooks=_user.GetBooks(); 
    } 
} 

die Book s gesammelt werden, hängt von dem User ausgewählt wurde. Jetzt ist es viel einfacher mit zu arbeiten.

Ich will nur wissen, was ein guter Ansatz ist nach MVC-Muster und Praktiken.

+0

Dies wäre einfacher zu lesen, wenn Sie den Code mit der Schaltfläche Code Sample formatieren würden. – RedFilter

+0

@OrbMan, ich habe mich nur darum für dich gekümmert. Ich habe das gleiche gedacht. – Sampson

Antwort

1

Sie können es auf mehrere Arten tun, aber ich würde sagen, der einfachste Weg wäre, die Referenz-ID für den Benutzer, auf den Sie zugreifen möchten, an die Controller-Aktion (wie unten) zu übergeben Führen Sie alle Datenzugriffsaufrufe durch.

public void GetUserAndDetails(Guid userId) { ... } 

Dann in dieser Controller-Aktion können Sie die Benutzerdaten und die Bücher für diesen Benutzer, legen Sie die Eigenschaften in der Ansicht Modellinstanz und gibt sie dem Blick auf den Zugang suchen.

FormViewModel model = new FormViewModel(); 
model.MyUser = GetUser(userId); 
model.UserBooks = GetUserBooks(userId); 
return View(model); 

Auf diese Weise bleibt die Ansicht dumm (was es sein sollte) und das Modell ist relativ einfach. Dies hilft auch bei Testzwecken.

Hoffe, das hilft.

1

Im Allgemeinen sollte diese Art von Arbeit im Modell durchgeführt werden. Dies hat mehrere Gründe. Erstens, wenn das Abrufen der Benutzerbücher eine Datenbankverbindung erfordert, möchten Sie dies nicht von der Ansicht aus tun - es wird nur verlangsamen. Die andere Sache zu erinnern ist, dass es mehrere Ansichten geben könnte, und Sie müssten diesen Code in allen Ansichten (Webclients, vielleicht Rich-Clients, usw.) duplizieren.

Im MVC-Muster sollten die Ansichten die "dummen" Teile sein. Dies ermöglicht die einfachere Verwendung mehrerer Ansichten und das Ändern von Ansichten bei Bedarf. Es ist auch einfacher, Code zu testen, wenn keine Ansicht erforderlich ist. So können Sie das Modell testen, ohne einen Webclient aufzurufen.

Jeff

5

Sie wollen alle Ihre Geschäftslogik trennen und Datenvalidierung in das Modell. In der Regel umfasst das "Gruppieren" von Datensätzen und das Filtern von Daten nach bestimmten Kriterien.

Sie möchten alle Aufrufe dieser Methoden des Modells in der Steuerung trennen, die dafür verantwortlich sind, Daten zu und von dem Modell abzurufen und zu versenden. Der Controller übergibt dann den zutreffenden Datensatz in die Ansicht.

Die Helfer sind Logik, die von der Ansicht verwendet wird, Präsentation Logik (nicht Business-Logik oder Validierung) wie Drucken Menüs und so.

In der Ansicht werden Sie die Helfer verwenden (oder nicht, sie sind nicht erforderlich, MVC richtig zu verwenden, aber sie "helfen": p) HTML, CSS und JS in den Browser zu schreiben. Sie können auch häufig verwendete Ansichtsmodule in Teilansichten aufteilen, die Sie in mehr als eine Ansicht einschließen können.

Sie können weitere separate Dinge in ein Ansichtsmodell, aber dann außerhalb der „strengen“ MVC Sie gehen. In diesem Fall würden Sie das ViewModel verwenden, um der Ansicht zu helfen, mit dem Modell zu interagieren - im Grunde ist das ViewModel ein modularer Controller. In diesem Fall würde der Controller viel weniger tun als das, was er schon tut.

Dies ist jedoch in der Regel für Webanwendungen Overkill. Da Web-Apps einen einzigen Ausführungsfluss haben (die Anforderung), werden Dinge in ein ViewModel getrennt. Im GUI-Code wird das ViewModel jedoch viel nützlicher (da GUIs viel mehr als einen einzigen Ausführungsprozess haben).

Sie möchten immer Geschäftslogik in das Modell, Zeitraum trennen. Denken Sie daran, dass Sie Ihren Controller nicht an Ihr Modell koppeln sollten, damit Sie Ihr Modell an anderen Controllern verwenden oder es sogar als Web-Service bereitstellen können.

this helps :)

1

es der Ansicht ist, die "stumm" ist. es zeigt nur die manipulierten Daten an.

der Controller holt einfach Daten aus dem Modell für die Ansicht ... wieder ist der Controller NUR ein zwischendurch.

das Modell macht alles. Es speichert die Daten und enthält die Klassen und Methoden, die es manipulieren.

+2

Ich würde nicht die Ansicht "dumm" nennen - nicht mit der Menge der Client-Side-Logik für JS und Client-Seite Präsentation wie CSS. Die Ansicht kann in vielen Fällen viel komplizierter als das Modell sein. Während ich Ihren Standpunkt sehe, und Sie haben Recht, wenn diese Logik in das Modell eingeht, ist die Ansicht keineswegs dumm. Der Controller sollte jedoch sehr klein sein und ich würde so weit gehen zu sagen, dass es "dumm" ist. :) – nlaq

+0

Ich denke, Sie verwirren das Modell mit seinen Persistenz und Geschäftslogik Bedenken."Erfasst Daten aus dem Modell" ist ein Nicht-Sequitur, und "das Modell macht alles" ist eine zu weit gefasste Aussage. – bzlm

0

MVC ist ein Muster für sich. Ich habe wirklich keine Erfahrung mit ASP.NET MVC, aber arbeitete mehrmals und MVC-Muster verwendet. Manchmal wird MVC mit anderen Entwicklungsmustern wie Herzschlag, Memento, Status ... verknüpft.

1

Wenn Sie ein Ansichtsmodell haben, das sich von Ihrem Domänenmodell unterscheidet, sollten Sie das Domänenmodell nicht dem Ansichtsmodell im Ansichtsmodell zuordnen. Es würde die Viewmodel-Klasse für mehr als eine Sache verantwortlich machen. Sie können das Mapping im Controller oder in einer Service-Schicht vornehmen.

1

Auschecken this. Sie sprechen über VIEW Modell, nicht Domänenmodell. Es gibt einen großen Unterschied. View-Modell sollte dumm sein, es ist nur ein Platzhalter für Daten, die Ihre Ansichten stärker typisiert werden können. Domain-Modell muss ein Herz Ihrer App sein, es muss ALL Geschäftslogik enthalten.

0

Für ein Modell ist keine Geschäftslogik zulässig! Es ist ein schlechtes Design! Ihre Logik muss in den Controllern und genauer gesagt: Platzieren Sie Ihre Logik in die Helfer (die Helfer könnten Ihre BLL und/oder DAL verbrauchen) und verwenden Sie dann Ihre Helfer in Ihren Controllern.

Verwandte Themen