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
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
Comment