Wie halten Sie die Anwendungslogik von der Benutzeroberfläche getrennt, wenn UI-Komponenten über integrierte Funktionen verfügen?

Question

Ich weiß, dass es wichtig ist, den Benutzerschnittstellencode vom Domänencode getrennt zu halten - die Anwendung ist leichter zu verstehen, zu pflegen, zu ändern und (manchmal) Fehler zu isolieren. Aber hier ist mein mentaler Block ...

Delphi kommt mit Komponenten mit Methoden, die tun, was ich will, z. B. eine RichText Memo-Komponente lässt mich mit Rich Text arbeiten. Andere Komponenten, wie das String Grid von TMS, tun nicht nur, was ich will, sondern ich habe extra für die Funktionalität bezahlt. Diese Funktionen setzen das R in RAD.

Es scheint unlogisch zu sein, meine eigenen Klassen zu schreiben, um Dinge zu tun, die jemand anderes schon für mich getan hat. Es erfindet das Rad neu [hat jemals versucht, direkt mit Rich Text zu arbeiten? :-)] Aber wenn ich die Funktionalität verwende, die in Komponenten wie diese eingebaut ist, dann werde ich am Ende mit viel vermischter UI und Domänencode enden - ich werde ein Formular mit dem größten Teil meines Codes in seinen Event-Handlern haben.

Wie gehen Sie mit diesem Problem um? ... Oder, wenn ich den Code, den andere bereits für mich geschrieben haben, weiter verwenden möchte, wie würden Sie vorschlagen, mich mit dem Thema zu beschäftigen?

Answer 1

Denken Sie zunächst daran, dass "Umgang mit Rich Text" nicht das ist, was Ihre App tun soll. Ihre App soll es dem Benutzer ermöglichen, eine bestimmte Aufgabe auszuführen, und der Code, der sich um diese Aufgabe kümmert, ist Ihre Domänenlogik. Wenn ein Teil der Aufgabe, die Ihr Programm ausführen muss, die Arbeit mit Rich Text umfasst, können Sie diesen Teil an eine Rich Text-Komponente delegieren. Die Komplexität kommt, wie Sie bereits erwähnt haben, an der Schnittstelle zwischen diesen Bibliotheken und der Domänenlogik.

Die Art und Weise, wie Delphi-Domänenlogik und Delphi-UI-Steuerelemente miteinander interagieren, erfolgt hauptsächlich über Ereignishandler. Das bedeutet jedoch nicht, dass Sie Ihre Domänenlogik selbst in die Ereignisbehandlungsroutinen einfügen müssen. Versuchen Sie stattdessen, Einheiten zu schreiben, die den Code für die domänenspezifischen Aufgaben enthalten, die Sie ausführen müssen, und lassen Sie die Ereignishandler diese Einheiten aufrufen.

Mit anderen Worten, schreiben Sie keine Klassen, um das Rad neu zu erfinden und Dinge zu tun, die andere bereits für Sie getan haben. Du hast recht, das wäre unlogisch. Aber schreiben Sie die anwendungsspezifischen Teile, die die Steuerelemente und Bibliotheken, die Sie nicht haben, als ihre eigenen separaten Klassen in ihren eigenen separaten Einheiten, und verbinden Sie sie über Ereignishandler und öffentliche Methoden oder Eigenschaften auf Ihren Formularen, und Sie werden Schluss mit einer ordentlichen Trennung der Sorgen.

Answer 2

Sie können eine saubere Trennung erstellen, indem Sie Datamodule mit clientDataSets verwenden, um Ihre Geschäftslogik und Datenobjekte zu enthalten. Sie könnten sogar noch einen Schritt weiter gehen und die Geschäftslogik von den Daten trennen. Offensichtlich enthält das Formular die Benutzeroberfläche. Fast jede Komponente, die Sie verwenden, kann datengebunden sein, was es einfach macht, sie an Ihre clientDataSets zu binden.

Denken Sie nur daran, dass Delphi eine Möglichkeit bietet, Dinge zu tun, die nicht immer zu den Best Practices von Java oder .Net passen. Dein Ziel sollte sein, etwas zu tun, das sich gut anfühlt und für Delphi funktioniert.