Verständnisprobleme MVP

[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.

[Ookami]

Nachtrag:

Stevie, ich habe mir das Projekt mal angeschaut. Alles habe ich noch nicht verstanden, dafür sind 5 Minuten zu kurz, aber ich kann zumindest sagen, dass man das nachvollziehen kann. Auch meine Vermutung, dass man MVP auf eine einfachere Art darstellen kann, hat sich bestätigt. Muss noch mal gesagt werden, Deine Art ist einfach und simpel.

Das man das was CustomerViewer mit der Main gemacht hast, war mir bislang nicht klar, dass man sowas überhaupt machen kann.

Nochmal ganz großes Danke und an alle, die sich ebenso schwer tun, schaut euch den Code an!