Stimmt beides.
1) Binding
Die
GUI-Controls sollen m.E. nicht die gesamte Datenschicht und schon gar nichts von der Businesslogik kennen.
Ein Edit soll nur wissen, dass es die Eigenschaft Name eines Objektes mit der ID 12345 darstellen und ggf. ändern soll.
Oder die Eigenschaft Caption des Objektes mit dem Namen "Form1".
Oder die Eigenschaft "Kennzeichen" eines Objektes mit dem Namen KFZ1.
Das Edit muss dann einen Manager beauftragen, das gewünschte Objekt zu finden und muss dann nachsehen, ob dieses die gewünschte Eigenschaft besitzt. Ggf. muss der Wert der Eigenschaft noch in einen anderen Datentyp umgewandelt werden.
Der Manager seinerseits kann nach bestimmten Regeln in der Datenschicht nach dem Objekt suchen oder z.B. auch per FindComponent innerhalb der
GUI. Dem Edit ist es somit egal, ob es an die Datenschicht gebunden ist oder an das Formularcaption.
Im Grunde ist es ähnlich wie ein DBEdit an ein Tabellenfeld zu binden - nur eben viel flexibler.
Die
GUI-Schicht selbst kennt dabei weder die Datenschicht noch umgekehrt.
2)
GUI-Logik
Die
GUI darf und muss natürlich selbst auch Logik erhalten aber das sollte sich wirklich konkret NUR auf die sichtbaren Aspekte beziehen.
Ein MaskEdit ist ein schönes Beispiel. Es akzeptiert selbst schon nicht, wenn ungültige Zeichen z.B. für ein Datum eingegeben werden.
Man könnte ähnliche Prüfungen auch im Formular durchführen, solange man dafür keine Analysen in der Datenschicht benötigt.
Wenn ich z.B. die Kinder für Personen erfasse und die Geburtsdaten prüfe (dass die Kinder nicht vor den Eltern geboren sind usw.) dann muss solch eine Prüfung in der Datenschicht erfolgen. Diese könnte eine Schnittstelle TPerson.KinderSindValide unterstützen.
ButtonOk.Enabled könnte an Person("#Aktuell").KinderSindValide gebunden werden. Dann kann ich die Person nur speichern, wenn die Datenschicht das erlaubt, ohne dass die
GUI wissen muss worum es geht.
Auf ungültige Zeichen prüfen kann man natürlich auch schon direkt in der
GUI, wobei ich mich frage, ob das immer Vorteile bringt.