Validierung in n-Tier asp.net mvc Anwendungen

Question

Ich bin auf der Suche nach einigen praktischen/theoretischen Informationen in Bezug auf Best Practices für die Validierung in asp.net mvc n-Tier-Anwendungen.

ich auf einer .Net-Anwendung arbeite in den folgenden Schichten unterteilt:

UI -> MVC3

BLL Schicht -> alle Geschäftsregeln. Entkoppelte von Datenzugriff und UI Schichten über Schnittstellen

DAL Schicht -> Datenzugriff mit dem Repository-Muster, EF4 und pocos

Nun, ich bin auf der Suche nach einer schönen, sauberen und transparenten Art und Weise meiner Validierungsregeln festlegen. Hier sind einige Gedanken zu diesem Thema:

UI Validierung sollte nur für Benutzereingaben und ihre Gültigkeit verantwortlich sein. Die BLL-Validierung sollte die Gültigkeit der Daten in Bezug auf die Anwendungsregeln berücksichtigen.

Mein Hauptanliegen ist, wie die BLL und UI-Validierung auf die effizienteste Weise zu binden. Eine Sache, die ich vermeiden möchte, ist die UI-Überprüfung in einer Sammlung von Validierung und das Hinzufügen von Fehlern manuell zum ModelState. Außerdem möchte ich den ModelState nicht an die BLL übergeben, um dort eingetragen zu werden.

Ich werde alle Gedanken zu diesem Thema schätzen.

P.S. Sollte diese Frage als Diskussion markiert werden?

Answer 1

Ihre BLL-Schicht könnte Validierungsfehler unter einem Standardformular wie zum Beispiel Dictionary<string, string> oder einem anderen benutzerdefinierten Typ zurückgeben. Der Controller empfängt ein Ansichtsmodell aus der Ansicht, sodass die Validierung für dieses Ansichtsmodell vom Standardmodellbinder aufgerufen wird. Wenn diese Validierung als nächstes passiert, kommen die Geschäftsregeln. Das Ansichtsmodell wird einem Modell zugeordnet und an die Serviceschicht übergeben. Bei Geschäftsfehlern würde der Dienst eine Sammlung von Fehlern zurückgeben, die mit einer Erweiterungsmethode auf dem Controller in den ModelState vom Controller eingefügt werden könnten.