Verwendung von Frames in Delphi zum Ausblenden von GUI-Informationen

Question

Ich lerne Delphi seit 3 ​​Jahren, auf Hobby-/Berufsebene. Ich freue mich sagen zu können, dass ich nun soweit bin, dass ich mit Entsetzen und Verlegenheit auf meinen frühen Code zurückblicken kann. Ich gehe jetzt einige meiner frühen Apps durch und überarbeite/refactoriere sie.

Eine der schlechten Angewohnheiten, von denen ich versuche wegzukommen, ist der Zugriff auf Komponenten auf einem Formular von einer anderen Einheit. Um dies zu erzwingen, experimentiere ich mit Frames als Methode zum Ausblenden von Informationen. Anstatt also ein Formular mit Komponenten auf sie zu haben, ich bin die Schaffung eines Rahmens alle Formularkomponenten zu halten, dann den Rahmen in einer Maske platzieren, Bewegen des Rahmens Erklärung in die privaten Erklärungen,

type 
    TMyForm = class(TForm) 
    private 
    MyFrame: TMyFrame; 
    procedure SetTimeDate(const Value: TMyItem); 
    function ReadTimeDate:TMyItem ; 

dann die Registrierung Rahmen in Form Initialisierungssektion

initialization 
begin 
RegisterClasses([TMyFrame]) 

erkläre ich dann die Eigenschaften I im öffentlichen Abschnitt des Formulars Einheit benötigen, die den Zugriff auf den Rahmen und seine Komponenten.

public 
    property TimeDate: TOverlayItem read ReadTimeDate write SetTimeDate; 

Ich verwende auch Rahmen, um häufig wiederholte Bauteilgruppen zu konsolidieren.

Dies scheint für die Zwecke zu funktionieren, die ich will (Myframe und seine Komponenten ausblenden), aber hat jemand andere Erfahrung mit dieser Methode?

Gibt es Nachteile bei der Verwendung von Rahmen? Profitiere ich davon? Gibt es Probleme mit verschachtelten Frames in Frames? Gibt es gute Anleitungen zur Verwendung von Frames in Delphi? Gibt es bessere/leichtere Möglichkeiten, den gleichen Effekt bezüglich der in Delphi versteckten GUI-Informationen zu erzielen?

HMCG

Answer 1

Es klingt wie Sie sind immer noch eine Menge Logik in Ihrer UI Schicht. Forms/Panels sollten nicht so viele Value-Eigenschaften haben (außer vielleicht für Dialoge).

Wenn Sie mehr Struktur als auf dem MVC-Muster lesen möchten.

Zusammenfassend kann Frames eine gute Möglichkeit sein, die GUI zu organisieren. Wie mit allem, übertreibe nicht.

Answer 2

Ich mag Rahmen allgemein zum Erstellen komplexer wiederverwendbarer Bits. Meistens denke ich, dass sie eine wirklich saubere Art sein können, Bildschirme zu bauen. Wie in Henk Holterman erwähnt, sollten Ihre Bildschirme und Frames jedoch nur eine Logik enthalten, die sich auf das Funktionieren der Benutzeroberfläche bezieht, und so wenig wie möglich über die Geschäftslogik informiert sein.

Ein paar Punkte wieder Frames und Informationen auf der Benutzeroberfläche versteckt:

1. Wie diskutiert in another question on StackOverflow Sie müssen vorsichtig sein, wenn in Ihrem Rahmen Ereignishandler verwenden.
2. Frames haben immer noch viele veröffentlichte Eigenschaften und lösen nicht wirklich das Problem, dass Formulare unpassend mit den Bits des anderen herumspielen können. Selbst wenn Sie es nicht tun, wird jemand, wenn der Code es zulässt, irgendwann Code schreiben, der manipuliert, wo er nicht sollte. Ich entferne immer die globale Formularvariable Delphi verschmutzt den Code mit Wrapperobjekten und schreibt oft Wrapperobjekte oder implementiert Schnittstellen, die kontrollierten Zugriff auf die Benutzerschnittstelle bieten.

So anstelle von Code wie folgt mit:

ClientForm := TClientViewForm.Create(Self); 
try 
    ClientForm.Client := MyClient; 
    ClientForm.ShowModal; 
finally 
    ClientForm.Free; 
end; 

ich in der Regel Menschen, etwas Derartiges zu schreiben zwingen werden:

ClientViewer := TClientViewer.Create(MyClient); 
try 
    ClientViewer.Show; 
finally 
    ClientViewer.Free; 
end; 

oder sogar

TClientViewer.ShowClient(MyClient); 

und lassen Sie die Klasse Methode ShowClient das Bit in der ersten li behandeln Stachel. Auf diese Weise empfängt der aufrufende Code niemals den Formzeiger und kann keine Bits berühren, die nicht speziell von der Wrapper-Klasse bereitgestellt werden.