2009-05-16 17 views
7

Hat jemand irgendwelche Links oder Ratschläge, wie Validierung, die Interaktion mit der Datenbank vor dem Aktualisieren oder Hinzufügen zur Datenbank erfordert verbinden? Jedes Beispiel, das ich sehe, zeigt, wie Eigenschaften z. "Ist erforderlich", "Ist E-Mail", "Ist Numerisch" usw., aber wie wird die Validierung für "Kann Artikel nicht vorrätig bestellen" durchgeführt? This xVal blog post berührt es, bietet aber kein Beispiel.asp.net mvc Datenbankinteraktion Validierung

Ich habe das NerdDinner-Tutorial verfolgt, das ein Repository verwendet, aber das ist das Bit, das ich nicht ganz verstehe ... Angenommen, wir hatten einen OrderController mit einer Create-Methode, und bevor wir einen Auftrag erstellen mussten Überprüfen Sie, ob der Artikel auf Lager ist. Im NerdDinner-Stil verwendet der Controller das Repository, um mit der Datenbank zu sprechen. Wie also könnte unser Order-Objekt (Model) diese Validierung zusammen mit der Property-Validierung erzwingen, da es nicht mit der Datenbank kommunizieren kann?

Vielen Dank für jede Hilfe

Antwort

0

Ich würde eine Orderservice mit einer Methode PlaceOrder (Order Reihenfolge) erstellen. Der OrderService verwendet das Repository, um CRUD-Operationen auszuführen und Geschäftsregeln (Bestandsüberprüfung) zu erzwingen und schließlich eine Regelverletzung auszulösen, die Sie abfangen und dem Benutzer melden können.

+0

Ich hatte gehofft, dies im Zusammenhang mit NerdDinner zu halten und im Moment keine Dienste zu nutzen. Ich möchte die Dinge so einfach wie möglich halten, um mich daran zu gewöhnen, wie alles angeschlossen ist. danke – atwrok8

3

Im NerdDinner-Lernprogramm können Sie die Methoden IsVaild und GetRuleViolation auschecken. Basierend auf Ihren Geschäfts- und Datenbankregeln können Sie diese verwenden, um die Daten vor dem Einfügen zu überprüfen. Sie können sogar eine IsValidForInsert-Methode erstellen, um alle einzufügenden Regeln zu überprüfen, die Sie erzwingen müssen.

In NerdDinner können Sie mit GetRuleViolation die verletzten Regeln abrufen und an die Schnittstelle sprudeln.

public bool IsValid 
    { 
     get { return (GetRuleViolations().Count() == 0); } 
    } 

    public IEnumerable<RuleViolation> GetRuleViolations() 
    { 


     if (CheckDbForViolation) 
      yield return new RuleViolation("Database Violation", "SomeField"); 

     if (String.IsNullOrEmpty(Title)) 
      yield return new RuleViolation("Title is required", "Title"); 

     if (String.IsNullOrEmpty(Description)) 
      yield return new RuleViolation("Description is required", "Description"); 

     if (String.IsNullOrEmpty(HostedBy)) 
      yield return new RuleViolation("HostedBy is required", "HostedBy"); 

... etc ... 


     yield break; 
    } 

    public bool CheckDbForViolation() 

    { 

    /// Do your database work here... 

    } 

Sie könnten dies weiter und teilen Sie den Datenbankcode in das Repository. Die CheckDbForViolation würde das Repo für die Informationen aufrufen und dann feststellen, ob ein Verstoß vorliegt oder nicht. In der Tat, wenn Sie ein Repository verwenden, denke ich, dass dies der bevorzugte Weg wäre.

+0

Ich habe über die IsValid und GetRuleViolations gelesen, aber es gibt keine Erwähnung des Szenarios "kann nicht ausverkauftem Artikel bestellen". Wo sollte diese Art von Geschäftsregel platziert werden? Danke – atwrok8

+0

Einer Ihrer Validierungsschritte wäre, die Datenbank zu durchsuchen, um zu sehen, ob der Artikel auf Lager ist. Fahren Sie dann entweder fort, wenn Sie gut sind, oder scheitern Sie und verhindern Sie, dass die Datenbank schreibt. –

+0

Ich verstehe, was der Validierungsschritt ist, aber WO würde die Logik gehen? Der Controller verwendet das Repository. Um die Datenbank abzufragen, müsste diese Logik im Controller vorhanden sein. Ich bin jedoch der Ansicht, dass Geschäftsregeln im Modell verbleiben sollten. Ich fange an zu denken, dass der Controller das Repository nicht benutzen sollte ?! danke – atwrok8

1

Sie brauchen keine Anleitung von Beispielen, wie dies zu tun ist. Letztendlich müssen Sie in der Lage sein, solche Anwendungen selbst zu erstellen, was bedeutet, kreativ zu sein.

Ich habe von Anfang an entschieden, weder die integrierte Validierungs- noch die Membership-API zu verwenden, um irgendwann nicht an ihre Grenzen zu stoßen.

Für Ihre Situation: Es ist ziemlich Standard.

den Fluss Ausführung Stellen Sie sich vor, wie folgt:

  1. Beitrag Form
  2. Validate Eingangsdatenformat ohne auf die Datenbank zu sprechen
  3. Wenn (2) Pass, dann bestätigen Sie die Eingabe von dem Punkt Geschäftsregeln/Datenintegrität. Hier sprechen Sie mit der Datenbank
  4. Wenn (3) bestanden dann führen Sie Ihre Operation, was auch immer es ist. Wenn es irgendwie fehlschlägt (möglicherweise blockieren Datenintegritätsregeln in der Datenbank die Operation, sagen Sie, dass Sie ein verwandtes Objekt aus dem anderen Browserfenster gelöscht haben), dann brechen Sie es ab und benachrichtigen Sie den Benutzer über einen Operationsfehler.

Versuchen Sie, die Controller-Methoden so leer wie möglich zu halten. Die Validierungs- und Operationslogik sollte in Ihren Modellen und Ihrer Geschäftslogik enthalten sein.Der Controller sollte grundsätzlich die eine beabsichtigte Operation versuchen und basierend auf dem zurückgegebenen Status nur die eine oder die andere Ansicht zurückgeben. Vielleicht ein paar mehr Optionen, aber nicht die ganze Ladung von Prüfungen für Benutzerrollen, Zugriffsrechte, Aufruf einiger Web-Dienste usw. Halten Sie es einfach.

P.S. Manchmal habe ich den Eindruck, dass die eingebauten Funktionen, die den meisten Entwicklern einfache Dinge vereinfachen sollen, dazu neigen, neue Hindernisse gegenüber den entfernten zu schaffen.

+0

Der Ausführungsablauf, den Sie aufgelistet haben, ist genau das, was ich tun würde, ich bin nur nicht sicher in Bezug auf das NerdDinner Beispiel, wo die Validierung platziert werden würde. Es würde für mich mehr Sinn ergeben, wenn das Auftragsobjekt das Repository verwendet und der Controller nur mit dem Auftragsobjekt sprach. Auf diese Weise kann das Order-Objekt mit beiden Validierungsarten umgehen, da es nun mit der Datenbank kommunizieren kann. Wäre das eine bessere Option, meinen Sie? danke – atwrok8

+0

Ich bin NerdDinner Beispiel nicht so vertraut. Wenn "Repository" eine Art Datenbankschicht darstellt, während es eine Zwischenschicht für Geschäftslogik gibt (Ihre Bestellung kann z. B. als Geschäftsobjekt betrachtet werden), ist es eindeutig falsch, dass ein Controller das Repository zu welchem ​​Zweck auch immer verwendet. Die Kommunikation sollte wie folgt aussehen: [Controller] <-> BLL <-> DAL. Manchmal benutzt man nur Modelle statt BLL, aber es stimmt nicht genau. Modelle sind nur dazu da, die Daten für eine anzuzeigende Ansicht zu packen. – User

Verwandte Themen