|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Im Allgemeinen gilt: je mehr Abstraktionen, desto flexibler die Anwendung (die Kommunikation). Ob der Code dabei übersichtlich bleibt, ist fraglich. Man kann auch Abstraktionen einführen, die wenig Sinn ergeben oder einfach nicht hilfreich sind. Klar hat man irgendwo Bindungen. Diese sollten aber - wenn möglich - an "festen" Ort (Controller) plaziert werden und nicht dort, wo am ehesten Änderungen stattfinden (GUI, gefolgt vom Model). Ein Muss ist auf jeden Fall, eine Abstraktion der GUI aus Sicht des Models, dieses darf die View nicht kennen. Anders herum ist es vllt nicht immer notwendig, aber "schöner", wenn man eine zusätzliche Schicht hat (Controller). Denken wir einmal an die Überarbeitung (Refactoring) unserer Business-Objekte (Schnittstellen "verschönern"): Hier wäre es gut, wenn man die GUI belassen kann, wie sie ist. @Hansa: Sorry, ich habe deinen Beitrag leider nicht verstanden (ich erkenne an deinem Code-Schnipsel weder OOP, noch wird mir eine Art Ironie ersichtlich). Ich erkenne nur, dass hier nicht getrennt werden wollte. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
- abhängig von der Logik werden wiederum Controls beeinflusst; zwar im kleinen Rahmen in diesem Beispiel, läuft trotzdem dem zuwider, was ich vor dem Quote schrieb. - Feedback direkt über ShowMessage ausgegeben. Diese Methode allein ist nicht unittestbar um zum Beispiel zu schauen, ob das mit dem nicht weiter zurück blättern klappt, wenn man schon vorne ist. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ohne negativ werten zu wollen (im Gegenteil): Ab und an frage ich mich ja dann doch, was es denn nun genau für einen Unterschied macht, ob ich bei Änderungen meiner Software meine Bindings nun im Quellcode, oder in einer separierten Deklarationsschicht umschreibe. Letztlich beides mit großer Wahrscheinlichkeit Textdateien, und "deployen" muss ich auch in beiden Fällen etwas. In der Quelle brauche ich lediglich meine Compilerumgebung statt Notepad - aber die sollte ich ja wohl tunlichst haben.
Nicht gleich hauen! Ich setze grad selbst radikale Abstraktionen in unserem Betrieb mit Nachdruck durch. Aber mir passiert es ja nun auch selbst gerne mal, dass ich vor lauter Streben nach Eleganz und Wohlgeformtheit die Praxis und den wirtschaftlichen Nutzen mal für eine Hand voll Stunden vergesse. Dabei selbst erwischt sag ich zu mir selbst: "Ach du verfluchter Theoretiker, das ist eine Maßlösung für einen Kunden, und es arbeiten max. 3 Leute daran, von denen 2 im selben Haus wohnen. Fertigwerden!" Es schubbelt aber doch ein wenig an der Berufsehre :) Was is wohl sagen will ist: In Maßen, so lange es der (auch längerfristigen) Produktivität dient, alles prima. Man muss nur höllisch aufpassen, dass sich da kein Selbstzweck entwickelt, was ausgesprochen leicht passiert. Im Alltagsgeschäft schaut es, bei mittelständischen Betrieben, zudem auch gerne mal so aus, dass Abstraktionen nach Bedarf entwickelt werden. Somit entsteht über Jahre ein Framework, dass immer mächtiger und hübscher wird - aber in vielen Iterationen/Versionen existiert, und da man anfangs fast nie alles bedenken kann was mal noch an Anforderungen kommt (einfach weil der Bedarf nie da war), man auch gerne zueinander inkompatible Stände hat. So dass das aktuelle Rahmenwerk nicht mehr zum Bearbeiten der ersten Hand voll Projekte auf dessen Basis dienen kann, weil zigfach geändert. Sowas geht erst dann gut, wenn einem entweder die frühen Kunden die Zeit geben und bezahlen die man in ein derart umfangreiches und flexibles Framework investieren müsste (teilweise reden wir ja schon über Frameframeworks...), oder der Betrieb kann es sich leisten eigens dafür ein Team von Informatikern in Vollzeit abzustellen, die am eigentlichen Geschäftsfeld sonst eher wenig beteiligt sind. Unter einer mutig geschätzten 50-Mann-Softwareschmiede wohl eher seltener anzutreffen, und auch dort wird man anfangs RAD-like Code produzieren (weil so ein Framework ist ja nicht in 10h geplant und gebaut bzw. angepasst/gelernt), der entweder teuer nachträglich verhübscht werden muss, oder man ihn als Legacy-Fessel durch die Jahre buckelt, spätestens bis die Zielplatform am Ende ist. Der wirtschaftlich nötige und sinnvolle Abstraktionsgrad ist, würde ich schätzen, einer der am schwersten abzuschätzenden Dinge in der Softwareentwicklung. Besonders weil seine Entwicklung ggf. selbst sehr viel Zeit bedarf, die man zwar auf die Gesamtheit aller je zu erstellenden Projekte positiv bilanzieren kann, sie aber schon vorab investieren muss, bevor man überhaupt auch nur ein Produkt verkaufen kann. Es sei denn, man verkauft Frameframeworks :mrgreen: Wenn es Kunden gäbe, die diese Dinge hinterblicken würden - DAMIT wäre uns wirklich sehr geholfen. Aber gebt mal einem Einkäufer diesen Thread hier zu lesen... Der schnallt doch ab! (Ausser er ist ungewöhnlich "open minded". Normal ist da reines Kurzfristigzahlenkleinhalten das einzige Programm im Hirncomputer.) Sö, ich bin nun bereit eure Knüppel in Empfang zu nehmen :) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
....keine Knüppel, +1
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Nun, es geht hier ja nicht um Übertreibungen sondern eigentlich um einige der einfachsten Software Prinzipien (z.B.
 SRP) Man kann das hier in diesem Thread beschriebene mit einfachen Mitteln realisieren, oder man kann es over engineeren. Natürlich kann man beim "klassischen Ansatz" bleiben, wenn es sich um ne 0815 Anwendung handelt und man dadurch nix gewinnt. Aber es mag auch Anwendungen geben, die über hunderttausende Zeilen Code gehen, mit hunderten von Forms und Frames. Gratulation, wer da noch bei dem klassischen Ansatz den Überblick behält. Ich kenne solchen Code nur zu gut, wo über Jahre immer neue Anforderungen in nem Form oder Frame implementiert wurden. Inzwischen sind das Monster geworden, die jeder einfach nur am liebsten in die Tonne kloppen und neu machen würde. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Klar, würde nach Jahren ohnehin anders arbeiten. Aber große Korrekturen sind jetzt vor allem wegen der Vermixung von Programmlogig und GUI-Controls kaum noch möglich. Ich brauche lange, bis ich erahnen kann, was ich damals programmiert habe ;-) Eine klare Trennung von Geschäftslogik und GUI würde dabei m.E. erheblich helfen. In Zukunft werde ich darauf achten. Es stellen sich nur zwei Fragen: - Wie komfortabel kann die die zwei Schichten verbinden? (Bisher geht das im Delphi ja nativ nicht so einfach.) - Kann ich mir für mein aktuelles Projekt (durch geringen Mehraufwand am Anfang) insgesamt Arbeit sparen? (Das trifft für große und komplexe Projekte ganz bestimmt zu.) Dann muss man darauf achten, dass die Programmlogik und die Formularanwendung jeweils komplett kompilierbar und funktionsfähig sind (wengleich man letzteres schwer vollständig testen kann), wenn der andere Part nicht existiert. Um mal ein kleines, überschaubares Projekt zu erstellen, würde ich auf eine solche Trennung auch verzichten. Aber sobald das Projekt doch ausgebaut werden soll, dann unbedingt... |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Hallo,
Zitat:
Bis bald Chemiker |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 12:49 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