Ich habe ein benutzerdefiniertes ViewModel definiert als:
%Vor%In meinem Edit-POST-Handler habe ich folgenden Eintrag:
%Vor%Das Bearbeitungsformular ist wie folgt eingerichtet:
%Vor%Und es explodiert einfach, ich bin mir nicht sicher was passiert, hat folgenden Fehler: Für dieses Objekt ist kein parameterloser Konstruktor definiert. Bestimmt vermisse ich hier etwas wirklich Offensichtliches. Irgendein Hintergrund, das GET funktioniert perfekt und zeigt das Dropdown von der SelectList wie erwartet an. Ich vermute, dass die automatische Bindung zurück an das benutzerdefinierte Ansichtsmodell ist, was fehlschlägt, aber nicht sicher, was damit zu tun ist.
Sie brauchen einen parameterlosen Konstruktor und ich glaube, dass die Eigenschaften öffentliche Setter haben müssen. Der Standardbinder erstellt das Objekt einen Konstruktor, der keine Parameter annimmt, dann Reflexion über die öffentlichen Eigenschaften verwendet Werte aus den Formular / Abfrage-Parameter eingestellt werden.
%Vor%Ich vermute jedoch, dass das, was Sie wirklich tun wollen, nicht das Ansichtsmodell, sondern das zugrunde liegende Widget-Modell und den Wert für die Auswahlliste im Formular-Post ist. Ich glaube nicht, dass der Binder in der Lage sein wird, eine SelectList bei Post zu rekonstruieren, da er nur den ausgewählten Wert in den Parametern hat.
%Vor%MVC erfordert bei stark typisierten Ansichten, dass die Ansicht die in dieser Ansicht verwendete Klasse erstellen kann. Dies bedeutet einen Konstruktor ohne Parameter. Und das macht Sinn. Leute, die MVC neu sind, werden ähnliche "huh?" Probleme, wenn sie vergessen / nicht, Parameter öffentlich zu machen, und alle damit verbundenen Fehler, die auftauchen, wenn die Ansicht versucht, sich zusammenzusetzen (im Gegensatz zu einem Compiler-Fehler).
Aber was in dieser Klasse von parameterlosen Konstruktorproblemen "interessant" ist, ist, wenn eine Eigenschaft Ihrer Klasse auch keinen parameterfreien Konstruktor hat. Ich denke, das ist der pessimistische Ansatz?
Nachdem ich etwas Zeit mit der Klasse SelectList verbracht habe - eine MVC-spezifische Klasse - wollte ich hoffentlich einigen Leuten helfen, ein paar Minuten / Stunden zu sparen.
Dieses wirklich wichtige Tool / Klasse für die Erstellung von Dropdown-Listen hat die folgenden Konstruktoren:
public SelectList (IEnumerable Elemente); public SelectList (IEnumerable Elemente, Objekt selectedValue); public SelectList (IEnumerable-Elemente, Zeichenfolge dataValueField, string dataTextField); public SelectList (IEnumerable-Elemente, Zeichenfolge dataValueField, string dataTextField, object selectedValue);
.. und daher, wenn dies Eigenschaften für Ihre Klasse sind (die für die Ansicht verwendete), wird MVC Ihnen den schwer fassbaren Fehler "Kein parameterloser Konstruktor" geben.
ABER, wenn Sie etwas wie eine Hilfsklasse erstellen, cut-n-paste den genauen Code aus Ihrer ursprünglichen Klasse und machen Sie dann diese Hilfsklasse zu einem Parameter (NICHT get / set) für Ihre ursprüngliche Klasse; Du bist gut zu gehen.
Und auf diese Weise können Sie eine einzige Ansicht für gets und posts verwenden. Was ist schöner:)
Persönlich hätte ich entweder den Compiler erstellt, um die Assoziationen und Anforderungen stark typisierter Ansichten zu erkennen, oder ich hätte das Dropdown (oder einen anderen "Kunden" der SelectList) einfach nicht funktionieren lassen, sondern mich gefragt, ob es eine bestimmte Ebene gibt der rekursiven Prüfung auf parameterless Konstruktoren.
Zum Glück scheint die aktuelle Version nur auf der obersten Ebene zu sein. Fühlt sich an wie ein Hack und ich hoffe, es ist von Design.
HTH.
Tags und Links asp.net-mvc binding viewmodel