ich beschäftige mich gerade mit der Validierung von Domain-Objekts.
Was ich genau darunter verstehe, habe ich am Ende des Beitrags angehängt.
Ich suche nun nach Validierungs-Frameworks, die unsere Entwickler unterstützen, speziell für .Net/C# oder Perl.
Frameworks, die einzelne Werte/Instanzen validieren, gibt es sehr viele.
Wer hat schon positive/negative Erfahrungen mit solchen Frameworks?
Validierungsframeworks, die Aggregate prüfen, habe ich bisher noch keine gefunden. Habe ich nur schlecht gesucht oder gibt es tatsächlich keine?
Wie kann man selbst ein Framework implementieren? Welche Zustände sollte man speichern (DB-Tabellen-Spalten)? Hat schon mal jemand ein Validierungs-Ranking implementiert? Denn wenn viel zu validieren ist, muss die SW ja irgendwo anfangen.
Validierung sollte jedenfalls AUSSERHALB des eigentlichen Domänen-Objekts in eigenen Klassen implementiert werden, damit sie nicht die Domänenklasse aufbläht und nachher nicht mehr klar ist, welche Methoden die Validierung und welche die eigentliche Objekt-Funktionalität bilden.

Siehe dazu auch mein Perl Modul Scalar::Validation auf dem CPAN.
Ich bin gespannt auf Eure Kommentare,
VG aus Duesseldorf
Ralf Peine
===========================================
Über die Validierung von Domain-Objects
===========================================
Validierung von Domänen Objekten ist nicht so einfach, wie es zunächst
scheint.
Es gibt mindestens 4 verschiedene Validierungslevel:
1. Ein einzelner Wert
2. Eine Instanz eines Domänenobjekts (DO-Instanz)
3. Ein Aggregat oder ein Baum/ein Graph/eine Menge von Domänen-Objekten
4. Prüfungen, die außerhalb des Einsatzbereichs des Domänen-Objekts
oder sogar von Fremdsystemen durchgeführt werden müssen
------------------------------
1. Validierung einzelner Werte
------------------------------
Einzelne Werte (Properties, Attribute) können auch während der
Eingabe, z.B. im GUI validiert (geprüft) werden. Sie müssen aber in
der DO-Instanz jedesmal validiert werden, weil z.B. durch
Fremdsysteme, SW-Fehler oder Änderungen an den Validierungsregeln seit
dem letzten Speichern unerlaubte Werte im DO-Instanz (ent-)stehen
könnten.
Praktisch wäre es, wenn sowohl bei der Eingabe als auch bei der
DO-Instanz-Validierung dieselben Regeln verwendet werden könnten.
Letztlich relevant ist aber nur die Validierung auf der DO-Instanz.
Invalide Werte sollten nicht in die DO-Instanz übernommen werden, was
aber wegen Regeländerungen und Validierungslevel 4. nicht immer
verhindert werden kann.
Nach dem Einladen einer Instanz kann so z.B. eine Validierung
den Zustand eines Parameters von "Valid" auf "Invalid" verändern.
----------------------------------
2. Validierung des Domänen-Objekts
----------------------------------
Hier werden die einzelnen Werte und Zustände in der DO-Instanz
miteinander überprüft. Sinnvoll ist das nur, wenn alle Werte,
die als Input für eine Prüfung verwendet werden, selbst valide sind.
Daher muss zunächst die Einzelprüfung (1.) durchgeführt
sein und alle ungültigen Parameter müssen dem Validator bekannt sein.
Dann können Regeln ausgeführt werden die mehrere Parameter
vergleichen, z.B.
-----------------------------
EintrittsDatum = 01.13.2012
Alle Prüfungen, die Eintrittsdatum verwenden, können nicht
durchgeführt werden, weil das Eintrittsdatum selbst nicht valide ist,
es gibt ja nur 12 Monate.
----------------------------
StartDatum = 01.10.2012
EndeDatum = 01.09.2012
Die Validierung von Start- und EndeDatum ist möglich, da Werte valide
sind, aber das Ergebnis ist "Invalid", da natürlich die
ValidierungsRegel: StartDatum <= EndeDatum
verletzt ist.
Damit ist die gesamte DO-Instanz "Invalid", und das muss protokolliert
werden. Ein Speichern der Instanz
-- inkl. des Validierungszustands --
muss aber trotzdem möglich sein.
Nach dem Laden einer DO-Instanz aus dem Repository (der DB) kann es
sinnvoll sein, sofort eine Validierung durchzuführen, auch wenn der
mitgeladene Validierungszustand == "Valid" ist. Auch dafür kann man
wieder Regeln definieren.
Eine Kreditkarte muss z.B. vor jedem Einsatz und während des Einsatzes
überprüft werden (s. externe Prüfungen, Level 4)
---------------------------------------
3. Validierung mehrerer Domänen-Objekte
---------------------------------------
In Level 3 werden ein Aggregat oder ein Baum/ein Graph/eine Menge von
DO-Instanzen validiert.
Beispiel:
Ein Bus soll von A nach B gefahren werden.
Dazu benötigt man die Kombination Fahrer/Bus, welche nur Valid ist,
(DO-Instanz-Prüfung)
wenn der LKW technisch ok, fahrbereit (bereift, betankt) und zugelassen (Zulassung, TÜV) ist,
wenn der Fahrer ausgeruht und verkehrstüchtig ist (Krankheit, Medikamente, Drogen, Brille, ...)
(Übergreifende Prüfung)
wenn der Fahrer eine Fahrerlaubnis für das Fahrzeug (Führerschein, Einweisung, ...) besitzt.
Einen leeren Bus darf man auch mit LKW-Führerschein fahren,
einen vollen nur mit Personenbeförderungsschein!
----------------------
4. Externe Validierung
----------------------
Ob das Fahrzeug wirklich zugelassen ist und ob die Fahrerlaubnis des
Fahrers echt und momentan gültig ist, darüber können nur die Polizei
(als Dienst) oder das Straßenverkehrsamt (direkt) Auskunft geben.
Eine Kreditkarte muss vor jedem Einsatz und während des Einsatzes
überprüft werden. Das kann nur das Kreditkarten-Institut durchführen.
--------------------
Wann wird validiert?
--------------------
Das muss für jedes Domänen-Objekt oder sogar für die DO-Instanz
wiederum über Regeln festgelegt werden, z.B.
Kreditkarten
------------
Kreditkarten-Daten müssen vor jeder Verwendung geprüft werden.
Straßenkarten
-------------
Straßen werden nicht so häufig umgebaut, man kann auch mit älteren
Karten (Alter < 3 Jahre) noch einigermaßen gut fahren. Wenn man
allerdings in Neubau-Gebiete fährt, sollte man am besten die
aktuellste Karte verwenden, die man sich besorgen kann.
------------------------
Was wird wo gespeichert?
------------------------
In der DO-Instanz sollten
- der Validierungszustand,
- das Datum der letzten Validierung
- und die SW-Version, mit der die Validierung erfolgt ist,
gespeichert werden.
Die Ergebnisse der Validierung, d.h. die fehlgeschlagenen Regeln
sollte man - wie die Regeln selbst -, außerhalb in eigenen
Klassen/Datenhaltung speichern.
---------------------------
Wie wird Validiert?
---------------------------
Dazu sollte man eigene Klassen für Regeln, Regelsets und Validatoren
erstellen.
Regeln können in der SW-kodiert sein oder dynamisch aus der Datenbank
geladen werden, z.B.
Auskodiert:
- Validate(Date datum)
- IsNotNull(Object object) { return object != null; }
- IsSmallerThan(int bound, int value) { return bound < value; }
Teilweise auskodiert:
- MatchesRegex(string regularExpressionString, string value)
hier kann der regularExpressionString aus der Datenhaltung stammen.
Vollständig dynamisch:
- EvalPerlRule(string ruleString, IList<string> valueList)
mit 
 
ruleString == "
sub Validate($wert1, $wert2, $wert3)  {
  if ($wert1 > $wert2) 
  { 
    if (defined $wert3) 
    { 
      return true; 
    } 
    return false; 
  }
  return true; 
}
";