Doc/View, MVC oder doch was ganz anderes?
-
Hallo!
Ich möchte anfangen ein GUI Programm mit wxWidgets zu schreiben. Nun stehe ich vor der Entscheidung welches Modell ich benutze.
Doc/View kenne ich von der MFC her. Da fand' ich's eigentlich relativ lästig damit zu programmieren, u.a. weil der (teilweise zusammenhängende) Code so stückchenweise über das gesamte Projekt verteilt war.
Über MVC habe ich neulich erst in einem Buch gelesen. Das Prinzip fand' ich ganz in Ordnung, weil es eben nicht so umständlich wie Doc/View ist. Doch dann habe ich diesen Artikel gelesen, der mir plötzlich einreden will, dass keines dieser Modelle zureichend ist und man am besten ohne sie arbeiten sollte.
Tja, nun würd' ich gern mal eure Meinung hören. Wie programmiert ihr GUIs und was sagt ihr zu dem Artikel (imho _sehr_ idealistisch)?MfG
-
This extract-data-then-shove-it-elsewhere approach requires you to know way too much about how the model-level objects are implemented.
Also bei mir muessen die Views nichts daruber wissen, wie das Model aussieht.
Ein View weiss, wie es aussieht und was fuer Daten es bekommt (das Model kann natuerlich auch ein Validierungscallback beim View registrieren um falsche eingaben direkt abzufangen) und reicht die Daten einfach weiter. Dem View ist es doch egal was mit den Daten gemacht wird.
Dem Model ist wiederum egal woher die Daten kommen, es verarbeitet sie einfach und sagt das Ergebnis dem Controller. Der sagt den Views dann, was sie jetzt machen sollen.
Ich sehe hier keine direkten Abhaengigkeiten...
In the simple example above, you're tasked with adding an employee ID to every name in every screen that displays employee names. In the RAD-style architecture, you'll have to modify every one of these screens by hand, modifying or adding widgets to accomodate the new ID field.
Ja, wenn man einfch nur Widgets in jede Form einfuegt kann soetwas passieren.
Wenn man aber dem Controller hier etwas arbeitet aufbuerdet, dann muss man nur dem Controller sagen, dass er jetzt noch ein 2. View erstellen soll.Wobei das halt wieder die Frage ist ob es sich lohnt, denn dank RAD kann man sowas ja in 10 Minuten aendern...
If you had simply encapsulated the identity into a Name class, none of this work would be necessary. The Name objects would simply display themselves in the new way. Two Name objects would now compare themselves using the ID information; your code that called fred.compareTo(ginger) or fred.equals(ginger) wouldn't have to change at all.
Bitte? Das kapier ich ueberhaupt nicht. Wenn ich einen neuen member irgendwo hinzufuege muss ich Code aendern. wie soll es ohne aendern moeglich sein?
Wenn wir jetzt mal nicht davon ausgehen, dass man alles per reflection loest (was ja extrem lahm waere (nicht nur in der laufzeit, sondern auch in der entwicklung).
So what's wrong with this picture? Let's start with the returned balance. What happens when Bill Gates walks into our bank wanting to open a non-interest-bearing checking account and put all his money in it? We really don't want to send him away, but the last time we looked, Bill was worth about 87.94 gigabucks (see Resources). Unfortunately, the 32-bit float we're using for the account balance can represent at most 20 megabucks (4 gigabucks, divided by 2 for the sign bit, divided by 100 for the cents). Similarly, the 16-bit int used for the PIN can hold at most four decimal digits. What if Bill wants to use "GATES" (five digits) for his PIN? The final issue is that the SQL queries are formulated by the ATM. If the underlying data dictionary changes (if the name of a field changes, for example), the SQL queries won't work any more.
Hier habe ich aufgehoert zu lesen.
Denn die richtigen Variablentypen zu verwenden hat nun wirklich nichts mit OOP vs. non OOP zu tun.Also mein Fazit: vergiss den Artikel. Ich fand ihn mies.
-
Shade Of Mine schrieb:
Also mein Fazit: vergiss den Artikel. Ich fand ihn mies.
Und das obwohl Allen Holub eine absolute Größe ist und so ein cooles Design-Pattern Buch geschrieben hat.Ich habe den Artikel vor laaaanger Zeit mal gelesen und weiß nur noch, dass ich die Idee sehr interessant fand. Allerdings erscheint mir das Ganze nur in einem Umfeld mit "Standard-GUI" sinnvoll zu sein. Sprich: Ok in Java (mit AWT bzw. SWING). In der chaotischen Welt von C++ aber problematisch.
MVC, streng umgesetzt, halte ich bei reale-Welt-Problemen für völlig ungeeignet (MVC-aus-dem-Buch hat bei mir bisher noch nie funktioniert).
Eine Trennung zwischen Model und View hingegen ist überaus wichtig. Nicht so sehr wegen der Wiederverwendung (die funktioniert bei mir in der Praxis so gut wie nie, trotz MVC). Vielmehr lassen sich Klassen mit nur einer Aufgabe leichter verstehen, erweitern und vorallem testen.Über MVC habe ich neulich erst in einem Buch gelesen. Das Prinzip fand' ich ganz in Ordnung, weil es eben nicht so umständlich wie Doc/View ist.
Doc/View ist eine Vereinfachung von MVC. Wie kann MVC da weniger umständlich sein? Verstehe ich ehrlich gesagt nicht.
Das Hauptproblem bei all diesen Ansätzen ist imo die schnell auftretene Redundanz von Daten sowie die Explosion von Klassen.
-
HumeSikkins schrieb:
Über MVC habe ich neulich erst in einem Buch gelesen. Das Prinzip fand' ich ganz in Ordnung, weil es eben nicht so umständlich wie Doc/View ist.
Doc/View ist eine Vereinfachung von MVC. Wie kann MVC da weniger umständlich sein? Verstehe ich ehrlich gesagt nicht.
Hmm, es ist relativ lange her, dass ich was mit der MFC(Doc/View) gemacht habe und MVC hatte ich mir bis dato auch nur kurz angeschaut. Hatte das wohl etwas missverstanden.
Was programmierst du denn lieber? MVC oder das einfachere Doc/View? Viele Leute sagen ja, dass Doc/View "schlecht" ist.Shade of Mine schrieb:
Hier habe ich aufgehoert zu lesen.
Ich fand', dass da der Artikel gerade interessant (und provokant) wurde. Er sagt, dass man völlig ohne Getter/Setter Methoden auskommen soll. Statt einem Objekt zu sagen: "Gib mir deine Daten, dann speichere ich Sie.", soll man sagen: "Speichere deine Date da.". Es werden also keine (naja, so wenig wie möglich) Rohdaten zwischen den Objekten mehr ausgetauscht (extract-data-then-shove-it-elsewhere). Ich bin mir aber ehrlich gesagt nicht sicher, ob sowas in einem realen Programm vernünftig machbar ist.
-
MVC funktioniert in der Form mit den gängigen Librarys nicht mehr, da diese ja Widgets als Design nehmen. Die Widgets kapseln dann ja bereits View und Controller. Doc/View ist deswegen angemessener und so wie ich das sehe auch üblicher.
-
HumeSikkins schrieb:
Und das obwohl Allen Holub eine absolute Größe ist und so ein cooles Design-Pattern Buch geschrieben hat.Mag sein. Ich habe ja auch nichts gegen den Autor gesagt, aber dieser Artikel ist IMHO mies.
Weil er keine richtigen Argumente bringt.
zB warum muss ich bei einem Prozedualen Ansatz ein Problem mit zu grossen Werten bekommen und bei einem OO Ansatz ist sowas nicht moeglich?Das fehlt irgendwie etwas...
Allerdings erscheint mir das Ganze nur in einem Umfeld mit "Standard-GUI" sinnvoll zu sein. Sprich: Ok in Java (mit AWT bzw. SWING). In der chaotischen Welt von C++ aber problematisch.
Und auch da nicht wirklich wiederverwendbar.
Denn wenn er dem Objekt seine Views direkt einbauen will "weil daten ja nur eine repraesentation haben" hast du schon bei soetwas einfachem wie:
Eingabemaske/Anzeigemaske schon grosse Probleme.Deshalb denke ich, dass es einfach flexibler ist, ein view zu haben. Denn das bindet dich nicht an eine GUI und eine Art der repraesentation.
Eine Trennung zwischen Model und View hingegen ist überaus wichtig. Nicht so sehr wegen der Wiederverwendung (die funktioniert bei mir in der Praxis so gut wie nie, trotz MVC). Vielmehr lassen sich Klassen mit nur einer Aufgabe leichter verstehen, erweitern und vorallem testen.
Wiederverwendung klappt bei mir bei aehnlichen Anwendungen recht super.
zB bei einem Frontend fuer eine DB (sowas schreibe ich in letzter zeit oefter) klappt es super einige komponenten zu uebernehmen.reines MVC habe ich auch noch nie 100% durchgezogen.
Das Hauptproblem bei all diesen Ansätzen ist imo die schnell auftretene Redundanz von Daten sowie die Explosion von Klassen.
Ja, aber kann die Loesung sein dass View in das Model zu integrieren?
Bei PHP funktioniert MVC zB viel besser. Weil du alle 3 Teile perfekt trennen kannst. Das View ist einfach ein Template, dass weiss, wie es bestimmte Daten darstellt, dabei kann man auch noch schoen Logisches View und Design View trennen
der Controller verwaltet die uebergabe der Daten von Model zu View - und es ist nicht moeglich direkt dem View daten zu geben, weil es technisch nicht moeglich ist. Und das Model ist dann der eigentliche PHP Code.ist absolut genial.
und man kann das logische View und den controller bei jeder neuen anwendung wieder uebernehmen und das design view wird teilweise angepasst. lediglich das model muss oft neugeschrieben werden.
sowas finde ich nett
hab es aber noch nciht geschafft das vernuenftig auf C++, Java & Co zu uebertragen, weil die Technik dort ganz anders ist...