Für alles andere als triviale Ansichtsmodelle verwende ich einen Ansichtsmodell-Builder, der die Verantwortung für die Generierung des Ansichtsmodellobjekts übernimmt. Im Moment nutze ich die Konstruktorinjektion der Builder in meine Controller, aber das riecht ein wenig, da der Builder wirklich davon abhängig ist, welche Aktionsmethode ausgeführt wird. Ich habe zwei Ideen im Kopf. Der erste Schritt würde einen benutzerdefinierten ActionFilter beinhalten, der es mir ermöglicht, jede Aktionsmethode mit dem entsprechenden Builder zu versehen, den Sie verwenden können. Die zweite Möglichkeit besteht darin, eine Überschreibung der View-Methode hinzuzufügen, die zum Akzeptieren eines generischen Objekts geöffnet ist.
So sieht mein Code derzeit aus. Beachten Sie, dass der Builder über den ctor injiziert wird.
%Vor%Hier ist die Option, wie eine aussehen würde:
%Vor%Oder Option zwei:
%Vor%Irgendwelche Gedanken oder Vorschläge wären großartig!
Ich denke, Sie könnten die Verantwortung für das Konstruieren des korrekten Ansichtsmodells auf den Builder verlagern. und Sie könnten den ViewModel-Typ übergeben, den Sie als Parameter erstellen möchten, etwa wie folgt:
%Vor%Mit dem obigen Ansatz erhalten Sie mehr Flexibilität in der Ansicht, die Sie innerhalb der Aktion rendern werden (was passiert, wenn Ihr Controller zwischen drei Ansichten wählen sollte, die angezeigt werden sollen und jeder ein anderes Anzeigemodell hat? Filterlösungen werden komplexer .)
Die Methode Ansichtsmethode verwendet das Modell und rendert die Ansicht . Es liegt in der Verantwortung des Controllers , das Modell zu erstellen . Da ich ein bisschen orthodox bin, würde ich empfehlen, die Modellbaulogik nicht in die View-Methode zu setzen:).
Tags und Links asp.net-mvc view architecture model