![]() |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Das stimmt, aber um so größer und komplexer ein Projekt werden wird, um so wichtiger wird eine Trennung.
Es ist eine Frage des Frameworks, wie komfortabel die Bindung der beiden Ebenen realisiert werden kann. Die Erstellung der Datenebene und der GUI-Ebene für sich sollte jeweils einfacher und übersichtlicher werden. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Punkt 1: stimmt absolut. Punkt 2: Ich weiß gerade nicht, was ich von Hand nicht machen könnte, was mir Bindings erlauben. Zitat:
Beim Binding muss man angeben, welche Property verwendet werden soll. Ich mache das mit Abstraktionen, die das - und nur das - enthalten, was der Benutzer der konkreten Implementierung wissen darf. Schnittstellen muss man immer angeben. Klar ist es mehr Aufwand, aber so viel auch wieder nicht: nach dem Anpassen der Schnittstelle, die richtigen Objekte erzeugen. Vorteil: der Compiler sagt mir, wenn ich falsche Informationen beziehen möchte. Zitat:
Dass der Controller das Model kennen muss, ist eigentlich kein Problem (meine Controller rufen nur Model-Methoden auf). Für den markierten Teil wird ein Presenter eingefügt, von dem der Controller auch nur die Abstraktion kennt. Meine Architektur: Model: klar! Controller: wählt zu Beginn den Presenter/die View aus; bestimmt, was die Anwendung kann; leitet Anweisungen an Model Presenter: UI-Logik (Weiterleiten von Eingaben); Formatierung der Ausgabe ;Erzeugen von UI-Objekten auf Anfrage des Controllers (auf Anfrage des Models) View: Leitet Eingabe-Events an den Presenter weiter; sieht trollig aus |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Memory Leaks gibt's auch: --------------------------- Unexpected Memory Leak --------------------------- An unexpected memory leak has occurred. The unexpected small block leaks are: 1 - 12 bytes: Unknown x 1 21 - 28 bytes: TList<System.TMethod> x 1 29 - 36 bytes: TEventHandlerInstance x 1 45 - 52 bytes: TEventHandler<DSharp.Bindings.TPropertyChangedEven t> x 1 69 - 76 bytes: TNotificationHandler<TEventHandler<DSharp.Bindings .TPropertyChangedEvent>> x 1 The sizes of unexpected leaked medium and large blocks are: 52012 --------------------------- OK --------------------------- |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Der Thread heißt "Trennung von GUI und Logik". Wenn du uns zeigen kannst, wie man ohne Vererbung diese gewünschte Trennung vollziehen kann, bin ich sofort ruhig. Bis dahin sage ich: Wieder am Thema vorbei. Was nützt es dem TE, wenn er es wissen will, oder wirklich benötigt? Ein Problem wegzureden, löst es nicht. Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Also ich will es unbedingt wissen und benötigen wird man es so oder so... :mrgreen:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
- Nativ ohne Framework-Einsatz (mein Code sollte einen Einblick gegeben haben, wo die Knackpunkte liegen) - "magische Lösung", bei der vieles versteckt wird und das Projekt schön klein bleibt. Wenn du es unbedingt (aus Bildungsgründen) zu Fuß machen möchtest, schaue dir folgende Pattern an: Observer, Visitor, Proxy |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Ich programmiere seit über 25 Jahren und bin der Meinung, dass hier extremst ubers Ziel hinausgeschossen wird. Das riecht verdammt nach OOP-Fetischismus *gg* |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:53 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz