Verständnisprobleme MVP

[Ookami]

ich wollte mich einmal wieder auf eine höhere Ebene der Programmierung pushen und habe mich in den vergangenen Wochen intensiver mit Interfaces und Design Patterns beschäftigt.
Für ein Projekt, an dem ich gerade arbeite, bietet sich insbesondere MVP an, soweit ich das Pattern verstanden habe.
Ich habe viel im Netz gesucht und bin auch teilweise fündig geworden. So richtig durchgestiegen bin ich dabei aber noch nicht. Ein Beispiel, das ich gefunden habe zeigt einen einfachen Sachverhalt, ist aber reichlich komplex aufgebaut und ich frage mich ob das nicht auch einfacher gehen könnte.
Leider aber, wie schon erwähnt, finde ich nicht mehr, auch hier im Forum nicht – oder ich hab’s übersehen.

Daher die Bitte an die, die sowas schon erfolgreich praktizieren:

Kann mir irgendjemand ein eigenes, sehr einfach gehaltenes Proof of Concept zur Verfügung stellen, anhand dem MVP sich nach Möglichkeit selbst erklärt.
Das Prinzip ist mir wohl verständlich, an der Umsetzung aber verknote ich mich total.

Grüße und Danke schon im Voraus.

[Ookami]

Hallo Gemeinde,

hat denn wirklich keiner ein Code-Snippet, das er/sie mir zur Verfügung stellen kann bzw. möchte?

Es muss nichts komplexes sein, nichts, was ihr in laufender Software verwendet.
So einfach wie möglich, einfach nur genug Code, damit ich das was MVP ausmacht in einem Code-Beispiel nachvollziehen kann.

Falls das nicht möglich ist, vielleicht kennt ihr Links auf irgendwelche Beispiele, die ich bislang nicht gesehen habe.
Hätte ich was ordentliches gefunden, würde ich euch nicht belästigen.

[Luckie]

Jetzt warte es doch mal ab. Es ist Feiertag. es ist langes Wochenende...

[Klaus01]

Guten Abend,

viellicht hilft dir das (simple start MVP with Delphi) hier weiter.

Grüße
Klaus

[Stevie]

Wenn man nach MVP oder Model View Presenter googelt wird man eigentlich mit genügend Material zu dem Thema zugeschüttet.
Klar ist das meiste eher nicht mit Delphi sondern eher mit C# oder Java Code Beispielen gespickt, aber das sollte eigentlich genügen, um das Prinzip zu verstehen.

Grundsätzlich kann ich sowieso empfehlen, sich beim Erlernen eines Patterns oder Prinzips nicht auf eine Sprache und deren konkrete Umsetzung zu beschränken.

[Ookami]

Hallo Klaus,

genau das Beispiel habe ich mir schon vorgenommen und ich finde es schlicht zuviel. Genauer gesagt, ich seh hier sehr viel Code für ein recht einfaches Problem. Es ist mir klar, das MVP aufgrund seines Aufbaus mehr Code erforderlich macht. Es ist jetzt halt am Anfang, ich denke, das kennt jeder von euch, schwierig einzuschätzen, ob das, was man sich so nebenbei ausdenkt denn auch richtig ist.
Vielleicht ist es ja genau das was MVP ausmacht und ich bin nur einfach zu blind, das zu sehen, lange Leitung oder so.


@Stevie
Ja, du hast recht, das meiste ist in C# oder Java. Zugeschüttet wurde ich auch, aber zum Verständnis hat es leider nicht beigetragen. Manchmal fand ich das auch wiedersprüchlich erklärt. Auch sowas hilft nicht wirklich zum Verständnis.

@Luckie
mach ich.

[Stevie]

Zitat von Ookami:

@Stevie
Ja, du hast recht, das meiste ist in C# oder Java. Zugeschüttet wurde ich auch, aber zum Verständnis hat es leider nicht beigetragen. Manchmal fand ich das auch wiedersprüchlich erklärt. Auch sowas hilft nicht wirklich zum Verständnis.

Dann hast du ja zumindest ein grundlegendes Wissen zu dem Thema - wenn ich mir z.B. den Wikipedia Artikel dazu durchlese, ist das schonmal ziemlich auf den Punkt gebracht und leicht verständlich - zumindest bis zu dem Punkt, wo Fowler das in die beiden anderen Modelle aufgeteilt hat.
Eventuell wäre es besser, konkrete Fragen zu dem Thema zu stellen. Oder zumindest könntest du darstellen, wie du bisher MVP verstanden hast.
Wie man genau MVP implementiert ist nämlich nicht in Stein gemeißelt sondern lässt einen gewissen Interpretationsspielraum zu - wie oft bei Entwurfsmustern.

Persönlich stimme ich aber Fowler bei seinen Erkenntnissen zu, die ihn dazu gebracht haben, von MVP wieder wegzugehen und ich bevorzuge die Richtung Passive View bzw MVVM (oder wie Fowler es nennt Presentation Model). Dort muss man (sofern man eine Bibliothek fürs Databinding hat) weniger individuellen Code schreiben, um die verschiedenen Teile miteinander zu verbinden.

[Ookami]

Hallo Stevie,

Zitat:

Wie man genau MVP implementiert ist nämlich nicht in Stein gemeißelt sondern lässt einen gewissen Interpretationsspielraum zu - wie oft bei Entwurfsmustern.

Vielleicht hat mir einfach dieser Satz gefehlt. Ich glaube zwar das das Problem tiefer sitzt, aber ich habe den Link, den Klaus01 empfohlen hat, den ich aber auch schon kannte mal ausgedruckt und im Flur ausgehängt, man stelle sich das Gesicht meiner Frau vor.

Nichts desto trotz werde ich mir das mal anschauen und durch den Kopf gehen lassen.

Der Wiki-Artikel war eines der ersten dich ich mir durchgeschaut habe. In dem Link den mir auch Klaus01 geschickt hat sind das 10 Units, nicht sehr groß, ist ja auch nur 'n Snippet zum Verständnis. Hier dachte ich einfach, das muss doch auch eine runde einfacher gehen. Wenn das aber der Weg ist, den man prinzipiell beschreiten muss, dann muss ich mich da eben durchwursteln und das eben erst mal so hinnehmen, wie es ist.

Das ist auch nicht weiters schlimm. Dauert dann eben länger.

Das mit den konkreten Fragen ist im Moment, wo ich nur das Gefühl habe der Gehirnteil, der sich mit MVP beschäftigt, ohnehin verwirrt ist, noch nicht so einfach. Deswegen auch die Bitte mit 'nem einfachen Snippet.

Zumindest werde ich mich auch mal mit dem anderen Pattern beschäftigen. Was ich bislang gelesen habe, gab mir das Gefühl nicht so ganz zu passen. Aber warum nicht?

[Stevie]

Ich hab mich mal an dieser Stackoverflow Antwort gehalten und nen kleines MVP Beispiel zusammengeschustert.

Der Knackpunkt beim MVP ist halt, dass die Ereignisse der View in den Presenter hineinfließen und die Aktionen wieder in die View. Somit kann man den Presenter testen, indem man bloß Events triggert und prüft, ob die erwarteten Aktionen eintreten. Und wenn ich die entsprechende View Schnittstelle so baue, dass sie nicht von bestimmten Implementierungsdetails der verwendeten Controls abhängen, dann ist die View auch sogar austauschbar (z.B. für andere UI Frameworks oder Plattformen)

[Ookami]

Hallo Stevie,

ich habe das gerade gesehen, noch nicht angeschaut, aber gleich geladen.

Erst mal ein ganz großes, dickes Danke.

Der Link kam mir auch gleich bekannt vor. Den hab ich mir auch schon mal reingezogen. Trotzdem Danke

Zitat:

Und wenn ich die entsprechende View Schnittstelle so baue, dass sie nicht von bestimmten Implementierungsdetails der verwendeten Controls abhängen, dann ist die View auch sogar austauschbar (z.B. für andere UI Frameworks oder Plattformen)

Das ist doch auch ein Teil des Grundgedankens beim MVP, zumindest so wie ich es verstanden habe.
Durch die Trennung von Model, welches die Daten lädt und zur Verfügung stellt, können diese an den Presenter geliefert werden, auf Anfrage gebrauchsfähig aufbereitet werden und so der View überreicht werden, die von alledem nichts weiss. Die Elemente M/V und P können schließlich ausgetauscht werden, ohne dass es die Funktion der übrigen Elemente betrifft, solange man sich nur an die Interfaces hält. Dies betrifft dann eben auch andere UI's oder Plattformen.

So zumindest habe ich MVP verstanden. MVC wollte ich nicht anwenden, weil mir da das Konzept nicht zusagt, zumindest für das Projekt, das ich demnächst angehen möchte.


Jetzt schaue ich mir erst mal an, was du da für mich gezaubert hast.
Nochmal Danke und ein schönes Wochenende.

PS: Bei Fragen werde ich mich nochmal melden.