Hallo zusammen
Ich habe zwei Methoden in einem Controller, eine für ein GET Request (wenn das Formular das erste Mal angezeigt wird) und eines für den POST Request (wenn der Benutzer auf senden geklickt hat und auch tatsächlich Daten gesendet wurden). Nun ist es aber so, dass bereits beim ersten Anzeigen des Formulars überall rote Warnhinweise stehen (weil das Model ungültig ist). Dies konnte ich nun lösen, indem ich ModelState.Clear() in der GET Methode definiert habe. Aber gibt es da nicht einen sinnvolleren Ansatz?
Beste Grüsse
Samuel
Code?
Aus deiner Beschreibung kann ich nicht ganz verstehen wie du arbeitest.
Bei ASP .NET gibt es eigentlich nur durch einen PostBack eine Validierung.
Aber ohne wirklich was von deiner Seite zu sehen kann ich nicht viel sagen.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Da er von ModelState redet nehme ich an, dass er MVC meint; und bei ASP.NET MVC gibt es kein Postback.
Kann das sein, dass Du bereits eine Entity bei Deiner GET-Methode übergibst?
Denn hier wird dann auch bereits der ModelState erstellt und Deine Werte validiert. Hättest Du aber gesehen, wenn Du das Debuggung-Feature von Visual Studio verwendet hättest...
In meinen Augen ist aber das "Binden" von Entities an die View absolut kontraproduktiv.
Das ist nen toller Gedanke bei MVC und ein nettes Features für die Evaluierung; aber in meinen Augen absolut unpraktikabel.
Ich verwende immer ViewModels für die Generigung der Ansichten und SubmitModels, die eine abgesendete Form repräsentieren. Von Entities direkt in die View legen halte ich nicht (mehr) viel.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Da hat Abt absolut Recht, Entitäten in einer View zu benutzen kann böse Fehler hervorrufen, z.B. wenn man die Entitäten nur teilweise zurückbekommt und diesen halben Zustand dann speichert.
In meinen Augen ist aber das "Binden" von Entities an die View absolut kontraproduktiv.
Das klingt ein bißchen wie eine Empfehlung, ich würde sogar soweit gehen, das Entitäten in einer View ein absolutes No-Go sind, etwas was man NIEMALS machen sollte.
MfG
Rabban
Naja das kann man so nicht ausdrücken.
MVC ist sehr nach verflochten mit dem EF; und alle Beispiele, die man so über das MVC-Framework findet nutzt das "Binden" von Entitäten an die View, bzw das Überladen.
Aber alle Beispiele haben mit der Realität halt einfach wenig zutun; gibt ja kaum eine View in der realen Welt, die nur die Entität widerspiegeln.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hi...
ich arbeite mit EF (Code First) und nachdem ich die Entitäen auch in anderen Projekten (Webservice, WPF-App,..) verwende, hab ich auf die Validierung mit den DataAnnotations verzichtet. Zusätzlich hab ich auch die Anforderung dass ich bei bestimmten Entitäen "situationsbedingte" Valdierungen brauch.
Deswegen mach das jetzt mit FluentValidation. Das ist sehr flexibel und ich kann auch bei Posts mit Ajax das reine ValidationResult zurückgeben.
Das mit den realitätsfremden Beispielen nervt mich auch immer. Da werden Entitäen an den View gebunden validiert und danach einfach in die Datenbank geschoben. Dabei wird aber leider immer davon ausgegangen, dass alle Felder im Formular enthalten sind. Das ist nun leider eher die Ausnahme. Und wenn man das so übernimmt überschreibt man sich gleich mal ein paar Werte mit "null" weil die Felder im Formular nicht enthalten waren oder es gibt überhaupt einen Fehler bei nicht nullable Feldern.
Ich verwende zwar keine eigenen PostViewModels aber der Ansatz ist ähnlich.
Ich hab mir eine eigene Funktion geschrieben die mir die Entität die ich grade aus der Datenbank geholt habe mit im Post enthaltenen Werten updated. Dann brauch ich nur noch validieren und speichern.