|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Schönes Thema mit kontroversen Meinungen. Zur Ehrenrettung der "Hab-Ich-Schon-Immer-So-Gemacht"-Fraktion sollte vielleicht nicht unerwähnt bleiben, dass viele Lösungsansätze in Delphi erst seit relativ kurzer Zeit zur Verfügung stehen.
Meine Motivation, den Delphi-RAD-Ansatz (teilweise) zu verlassen, kommt aus der Einsicht, durchgängig testbaren Code zu entwickeln. M. Hevery (Chef-Tester von Google) hat die Vorteile von Data-Binding so zusammengefasst: - MVC leidet naturgemäß an zirkulären Referenzen, die Probleme erzeugen und Unit-Testing sehr erschweren. - Data-Binding kehrt den normalen Ablauf der Abhängigkeiten um, erlaubt es zirkuläre Referenzen zu vermeiden und weniger gekoppelte Systeme zu erzeugen. - Data-Binding eliminiert viel Boiler-Plate-Code, der die Daten zwischen Model und View hin und her transportiert und macht unseren Code leichter lesbar und verständlicher. Dieses Mantra hat er  hier 2010 veröffentlicht und 1 Jahr später gibt es nun Delphi-Ansätze (aber nur für die letzten Versionen), wie man das Data-Binding nutzen kann.N. Hodge (ehem. Delphi-Manager) hat in Zusammenhang mit Dependency-Injection hier gefordert:Regel 1: Codiere immer mit/gegen Interfaces Regel 2: Halte den Constructor einfach Mit einem geeigneten Framework wie Emballo ("nimmt Interfaces den Schrecken") oder Stevies DSharp schreibt man nun Programme, die sich auf einmal "richtig" anfühlen. Auch wenn man es zurzeit noch nicht nutzt: Tests, Mockups, GUI-Austausch, verschiedene OS - das alles ist auf einmal greifbar nahe.(Nicht nur HP's letzter Haken zeigt: Die IT-Zukunft wird durch die Software bestimmt. Und mir ist dabei wichtig, bei all den Wechseln gelassen bleiben zu können und bei Ziel-Plattform und -OS die zu bedienen, für die sich letztlich meine Kunden entscheiden.) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
[Edit]
sowas ähnliches was neo4a sagt... nur ohne die quellen...und nur binding mag ich nicht ganz so... habe da in Javafx wirklich schlechte Erfahrungen mit gesammtelt. [/Edit] Zitat:
Andererseits will ich nicht wirklich Zwischenebenen einbauen die jeweils 2 oder alles Teile Kennen und quasi eine Postkasten(Messagequeue) Funktion erfüllen. Die einfachste möglichkeit sehe ich also darin IControler, IView und IModel zu definieren und jeweils gegenseitig zu registrieren. Wichtig dabei ist das es NICHT ein IView, IControler und IModel gibt sondern das es durchaus möglich ist das ich weiter aufteile und ableite IStammdatenView, IStammdatenControler, IStammdatenModel IBewegungsdatenView, IBewegungsdatenControler, IBewegungsdatenModel usw. Klassen die diese Interfaces implemtieren lassen sich dann einfach einander als Interface Registrieren egal was am ende wirklich da bedient wird. Es ist dann auch egal ob das Formular Spaghetticode enthält, weil für die Betrachtunge der Gesammtaufgabe braucht man sich nur an den Interfacedefinition orientieren und im Kleinen ist Spaghetti code ertragbar(verzicht auf binding). Leider habe ich noch kein Programm gesehen das auf diese Art und weise entwickelt wurde... außer eines...aber da wurde kein Interface benutzt sondern jede ebene jedes Anwendungsfalles mit einem Webservice dargestellt(StammdatenViewWebservice,StammdatenCon trolerWebservice,StammdatenModelWebservice) und SOAP legt die Zugriffsmöglichkeiten ja auch ziemlich gut fest ohne das man sich gegenseitig ganz genau kennen muss ähnlich wie Interface...man muss eben nur die Adresse wissen. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics. Ich hab jetzt noch nicht mit Google gesucht, aber gibt es denn weitere Binding-Komponenten?
Wenn ich das richtig verstehe konnte man bisher eigentlich nur mit MVC eine Trennung durchführen. DSharp gefällt mir echt gut und ich experimentiere damit jetzt etwas rum. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
FÜr mich ist MVC mehr ein Gedanke, die Umsetzung im Detail entspricht auch nicht dem "Standard" (den es ja so garnicht gibt). Entwurfsmuster sind ja nur grobe Ideen (die Philosophie einer Problemlösung) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
@DivBy0 + Luckie
Die Generics sind dabei nicht so maßgeblich, aber die neue RTTI ist eine Voraussetzung für die Bindung von außen. Das anzubindende Objekt muss z.B. untersucht werden, ob das anzuzeigende property "Text" vorhanden ist. Das ist mit der älteren RTTI in dem Umfang nicht möglich. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
ersten Blogposts erläutert. Es gibt einige Mechanismen auch in anderen Komponenten (die data sensitiven Controls, wo man z.B. den Fieldname setzt). Ich kann auch schon in Delphi 7 und früher 2 Objekte verbinden, und sie miteinander kommunizieren lassen, ohne, dass sie sich gegenseitig kennen müssen. Meine Grenzen sind aber nunmal da, wo die Sprachunterstützung aufhört. Der größte Kritikpunkt wurde ja schon genannt, es ist string basiert, da es keinen language/compiler support für property binding gibt. Und die Notifications bei der Änderung einer Property muss auch selber implementiert werden, damit die angeschlossenen Bindings darüber informiert werden und die Gegenseite aktualisieren. Beides Dinge die meiner Meinung nach einfach zu implementieren wären und einen großen Schritt auch für RAD bedeuten würden.Es gibt einige entscheidende Gründe, warum die derzeitige Lösung ab 2010 funktioniert - ich glaube aber alles davon könnte mit Abstrichen hier und da anders implementiert werden, um es auch in alten Delphi Versionen lauffähig zu machen:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zeitsprung, Irgendwann ein paar Wochen vorher: Mitarbeiter B hat die Aufgabe, eine Exportfunktion zu schreiben, die die Ausgabe, die an Stelle X gemacht wird, enthält. Das Sind Daten, die ein zulieferer zu Produktion von Teilen benötigt. Er kopiert genau den fehlerhaften Teil, anstelle ihn wiederverwendbar zu machen und zu benutzen (würde länger dauern, ist 'nicht pragmatisch', der Code ist mit der Kopie besser lesbar, und sowieso ist das ja eher RAD und das andere OOP Overkill). Was genau das Problem ist? Der Fehler ist jetzt immer noch am Programm, denn Mitarbeiter A hat den Fehler an Stelle X und gefixt und, weitsichtig wie er war, sogar noch geschaut von welchen Stellen der Code noch benutzt wird. An einer weiteren Stelle musste die Ausgabe noch um die, jetzt korrekte, Einheit angepasst werden, aber mehr war nicht zu machen. Das der Code von einem anderen Kollegen an Stelle Y kopiert wurde, davon weiss er nichts. Selbst wenn er mit so etwas rechnen müsste und er bei seinen Kollegen fragt, kann sich B nicht mehr daran erinnern, genau den Code verwendet zu haben. Ist ja schon ein paar Wochen her, und die Exportfunktion schon lange vergessen. Ohne zu wissen, dass der Fehler jetzt an stelle B immer noch im Programm (und damit im Export für den Zulieferer) ist - er sieht das korrekte Ergebnis ja an Stelle A - bestellt der Kunde anhand der Daten einen Großauftrag beim Zulieferer. Die gelieferten Kabelbäume für den A380 sind zu kurz - es gibt einen Millionenschaden. Weil irgendjemand Copy & Paste benutzt hat. Zitat:
Ich würde jede Wette eingehen, die Sicherheit und die Zuverlässigkeit, die eine sauber aufgesetzte Applikation bietet (im Sinne von: Fehler fallen durch automatisierte Tests sofort auf, durch saubere Trennung ist alles Testbar, durch saubere Trennung lassen sich neue Features leichter und schneller einbauen, weil sie schon funktionierenden Code absolut nicht beeinflussen können), wiegen den scheinbaren Vorteil den RAD bietet (ein wenig schneller bis zum ersten sichtbaren Ergebnis) um längen auf. Und zwar in nahezu jedem einzelnen Fall. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
In meiner über 30 jährigen Laufbahn als Softwareentwickler konnte ich noch _nie_ eine komplette Klasse eines Projektes in einem anderen Projekt wiederverwenden, aber hunderte von Funktionen die ich einfach aus meiner Sammlung kopiere und eine Funktionsunit einfügen kann (oder aber in dll's die von mehreren Programmen wiederverwendet werden können). Nun jedermann soll vorgehen wie es die Firmenpolitik vorgibt oder der jeweilige Einzelprogrammierer es mag. Solange ich keine masochistischen Gelüste in mir spüre, verwende _ich_ für Projekte mit einer GUI ein RAD-Tool. Manchmal kommt es mir vor, gewisse Programmierer arbeiten nach Zeilenentschädigung (das habe ich vor über 30 Jahren auch gemacht als freischaffender Journalist für Computerzeitschriften, da habe ich auch des öftern meinen Code aufgeblasen um mehr Geld für die Finanzierung des Studiums zu erhalten - und hunderte haben dann diesen Code mühsam abgetippt ;-). |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Und wenn du feststellst, dass die Funktion in der Sammlung einen Fehler enthält, dann durch suchst du alle deine Projekte um dann in jedem einzelnen den Fehler zu beheben? Wenn du nicht zentral auf diese eine Unit zugreifen willst (Ist immer etwas mühsam, wenn man es OpenSource verteilt, alle benötigten Units für das Archiv zusammenzusuchen.), dann ändere den Fehler in der Unit und kopiere sie in den Projektordner der betroffenen Projekte. Wenn du dann noch Buildscripte verwendest, brauchst du noch nicht mal die IDE zu öffnen. So mache ich das immer.
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 10:46 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