Ich habe eine MVC 3 App und ich habe ein generisches Wrapper-Objekt erstellt, das einige Navigationseigenschaften und das eingewickelte Objekt von T hat, deren Werte ich bearbeite/zeige.MVC 3 Split-Parameter in HttpPost Aktion
public class NavigationViewModel<T>
{
public T Model { get; set; }
public NavigationHelper NavigationHelper { get; set; }
public NavigationViewModel() { }
public NavigationViewModel(T model, NavigationHelper helper)
{
this.Model = model;
this.NavigationHelper = helper;
}
}
Mein Controller löst dieses Objekt schön in einer Aktion wie folgt aus:
public ActionResult Foo(NavigationViewModel<Bar> viewModel)
-Code aus meiner Sicht wie folgt aussieht:
@Html.EditorFor(model => model.Model.SomeProperty)
Mein Kollege sagte, dass dieser Code nicht schön lesen. Ich habe bereits eine stark typisierte Ansicht, das Modell und dieses Modell hat eine andere Eigenschaft namens Modell. Er schlug vor, die Model-Eigenschaft in ViewModel umzubenennen, und ich stimmte seiner Argumentation zu.
Jetzt funktioniert der Code mit den umbenannten Eigenschaften nicht mehr: NavigationViewModel viewModel ist null. Also änderte ich die Unterschrift des Httppost-Methode auf die folgende und es funktioniert wieder:
[HttpPost]
public ActionResult Foo(NavigationHelper helper, Bar viewModel)
ich das gefällt mir sehr gut! Ich kann direkt auf mein ViewModel im Code zugreifen, der Code in der View macht Sinn und das Helper-Objekt steht nicht im Weg. Ich habe diese Konvention noch nicht gesehen und ich denke, dass es vorher wegen der Namenskonvention funktioniert hat. Mit einer Eigenschaft namens Model wurde angedeutet, wie das Objekt aufgelöst werden kann. Ohne diese Eigenschaft konnte es nicht mehr aufgelöst werden.
Ich möchte dies für andere Arten von Helfern, die Ansicht-spezifische Eigenschaften, wie Select-Listen oder andere Eigenschaften, die ich sonst in meinem ViewBag haben könnte, zu übernehmen. Würdest du diesen Ansatz empfehlen oder bekomme ich später Probleme damit?
Generika sind gut, aber oft führen sie zu Over-Engineering. Was versuchst du zu erreichen? In Bezug auf die Namenskonventionen denke ich, dass Ihr Kollege Recht hat, aber nur ein View-Modell zu nennen, löst ein halbes Problem. Ich würde erwarten, in der Lage zu sein, den Zweck der Klasse nur zu identifizieren, indem ich auf seinen Namen und Eigenschaften schaue. –
Das Navigationsansichtsmodell ist ein Vehikel, um alle Arten von Informationen zu markieren, wie zum Beispiel welche Taste gedrückt wurde, um das Postback zu verursachen, und ob ich Buttons anzeigen möchte (wir gestalten einen sehr dynamischen und seltsamen Fluss). Ich kann diesen Teil wiederverwenden und das T, das Viewmodel, austauschbar machen. Es mag nicht klarer sein, es als Viewmodel zu bezeichnen, aber es hat mich dazu gebracht zu entdecken, dass man den Modellbinder dazu benutzen kann, zwei Objekte zu lösen, anstatt einen Wrapper mit einem inneren Objekt. – Vincent
Das klingt nach Designproblemen. Korrigieren Sie mich, wenn ich falsch liege, aber Sie sagen, dass Sie den Status der Seite verfolgen möchten, mit der der Benutzer gerade arbeitet. Wenn dies der Fall ist, könnten Webformulare eine bessere Lösung dafür sein. Auch das Hören von "Post-Backs" mit MVC klingt falsch. Vielleicht versuchen Sie mehr Informationen über Ihr Design zu teilen? Wie auch immer, das ist ziemlich interessant und es wäre gut, mehr Meinungen zu sehen. –