Duplizierung von Anwendungslogik vermeiden

[M.Pannier]

Hallo,
ich habe eine recht allgemeine Frage zum Anwendungsdesign bezüglich der Prüfung von so genannten Geschäftsregeln bzw. von Benutzereingaben: Wo bringe ich diese am besten unter, ohne die Prüfung/Eingabe doppelt und dreifach implementieren zu müssen?

Hintergrund: In den "guten alten Delphi Zeiten", als man noch ein DBEdit mit einer DataSource und diese mit einer DataSet/Table Komponente verbunden hat, war die Validierung recht einfach. Über das "select" der DataSet Instanz
und dem Erstellen der Felder wurden die Regeln aus der DB bereits in das DataSet und von dort aus in die DBEdits übertragen. Z.B.: Not Null Felder; Datentypen wie Float, Integer oder Strings; selbst die Prüfung auf einen
bestimmten Wertebereich (zwischen 0 und 100) waren relativ einfach möglich. Man musste sich nur beim Design der DB Mühe geben und die DataSet Komponenten mit der "DB/Tabelle" verbinden und hatte seine Prüfung. Spätestens beim Post kam eine entsprechende Fehlermeldung.

Seit geraumer Zeit sprechen alle nur noch von OOP, Pattern, O/R Mapping, Geschäftsobjekte usw. Der Grundgedanke ist ja auch OK und den habe ich auch verstanden, doch stellt sich mir die oben genannte Frage Wo man die Eingabevalidierung vorzunehmen hat.

Um dem neuem Schema OOP gerecht zu werden baue ich mir also ein Objekt, welches aus der DB gefüllt wird und von einem Formular zur Anzeige verwendet wird. Anschließend werden die Eingaben aus dem Formular wieder zurück in das Objekt geschrieben und von da aus in die DB. Wo setzt nun die Datenvalidierung an? Einfache Beispiele dazu gibt es in Hülle und Fülle. Aber halt nur einfache ohne "Datenvalidierung".

Ich müsste ja jetzt meinem Edit manuell alle Eigenschaften wie Required, MaxLength, Wertebereiche usw. verpassen, bzw. bei OnChange darauf Reagieren (erste Implementierung Logik). Dann müsste ich meinen Objekten ebenfalls die Logik beibringen (2. mal) Z.B.: bei einer Setter Methode für z.B.: Menge die Prüfung Wert > 0; Und zum Schluss besitzt meine DB ebenfalls die
entsprechende Logik. (3. mal)

Noch verrückter wird das ganze, wenn man noch einen WebService zwischen der Client-Anwendung (Präsentation) und der DB einschiebt. Dieser prüft ja ebenfalls seine Eingaben. (4. mal)

Habe ich da nur einen Denkfehler? Oder sind es die Dinge die Delphi vorher für mich gemacht hat und die ich jetzt selber machen muss?

Beste Grüße
M. Pannier

[Christian Marquardt]

Warum sollten dein Modell, der Webservice oder die DB die Logik zur Validierung implementieren?

Des Weiteren ist zwischen folgenden Validierungen zu unterscheiden:

- prüfen auf gültige Eingabe (bsp. nur Ziffern o.a.)
- prüfen der kompletten Eingabe auf Gültigkeit (bsp. bestimte Worte, Bereiche)

Ersteres wird sicherlich am Control bei der Zeicheneingabe direkt durchgeführt.
Letzteres kann sicherlich frühestens beim Verlassen des Controls und spätestens beim zurückschreiben der Daten in das Modell durchgeführt werden. hängt davon ab, wie die Eingaben erfolgen, ob es ein "Abbruch" gibt, welches die alten Daten wieder restaurieren muss u.a

[fanderlf]

Ich beschäftige mich zur Zeit auch mit dem Thema entkoppeln von Business Logik/Anzeige usw.

Gerade den Ansatz des Model-View-Presenters oder auch Model-View-Controllers finde ich sehr gut. Einen guten Einstieg liefert das hier:

http://blog.vuscode.com/malovicn/arc..._-pattern.aspx

Evtl. hilft Dir das ja weiter.

[M.Pannier]

Erstmal Danke für die Antworten.
@Christian: OK. Man muss zwischen diesen beiden "Validierungen" unterscheiden. Da muss ich Dir recht geben und das auch für mich besser verdeutlichen. Hier mal ein konkretes Beispiel. Man nehme eine Feld Menge, welches ein Pflichtfeld ist und dessen Werte > 0 sein muss. Also Tabelle angelegt mit einer Domain not null und einem Check Constraint Value > 0; Damit habe ich die Logik das 1. mal in der DB implementiert. Dann Objekt gebaut, Property Menge und eine entsprechende Setter Methode implementiert; Da im Delphi der Datentyp Integer verwendet wird, muss ich mich um das "Pflichtfeld" nicht mehr kümmern, sondern nur eine Prüfung Value > 0. Also habe ich die Logik ein 2. mal implementiert. Jetzt das Formular mit einem Edit bzw. "IntegerEdit". Hier müsste zum einen die Eingabe prüfen, das es auch wirklich ein Integer ist und auch kein Leerstring. Und das ganze bevor die Daten in das Objekt geschrieben werden. Denn wenn das Objekt eine Exception wirft (Setter Menge), dann stehen evtl. schon andere Werte im Objekt drin und das Objekt an sich ist nicht mehr konstistent. Also 3. Mal Logik implementiert. Jetzt noch der Fall Webserverice. Da der WS ja auch von sonst wo aufgerufen werden könnte, muss ich die eingehende Werte ebenfalls prüfen, also Menge > 0. Das wäre die 4. Implementierung der Validierung/Prüfung der Geschäftslogik.

@fanderlf: Danke. Davon habe ich auch schon gehört. Das Tutorial kenne ich aber noch nicht. Mal in Ruhe durcharbeiten.

Grüße
M. Pannier

[Christian Marquardt]

Es bleibt weiterhin unklar, warum in der DB und in den Settern Prüfungen drin sein müssen.

Wenn das Modell nur über das Eingabefeld belegt werden kann, ist eine Prüfung überflüssig (Prüfungen an der Eingabe im "View"). Des Weiteren in der DB. Wird die DB nur über das Modell beschrieben, kann kein falscher Wert in die DB geschrieben werden.

[M.Pannier]

Hallo,

Das Modell kann nicht nur von dem einen View beschrieben werden. Selbst in der eigenen bzw. der gleichen Anwendung könnte es vorkommen, das mehrere Views bzw. auch andere Geschäftsobjekte die Property Menge verändern. Die Prüfung nur im View und nur in der DB reicht meiner Meinung nach nicht. Nur das man dann die Prüfung doppelt implementieren müsste.

Problematisch wird es auch, wenn man einen Win32 Client und einen WebClient hat. Beide verwenden das gleiche Geschäftsobjekt. Ein Entwickler baut den Web und einer den Win Client. Einer vergisst eine Prüfung und schon kommen evtl. falsche Daten in der DB bzw. im Modell an! Wenn diese falschen Daten dann im Modell sind und dieses noch weitere Operationen durchführt, dann könnten falschen Ergebnissen raus kommen.

mfg
M. Pannier