MVVM - MVC wer macht was, was ist möglich....

[noisy_master]

Hallo liebe Gemeinde,

im Rahmen der Umstrukturierung meiner alten SW Projekt bin ich z.Zt. dabei mich mit den MVVM /MVC Konzepten auseinanderzusetzen, aber so ein paar Fragen habe ich immer noch:

einfaches Beispiel: View mit 3 Buttons( mehr, weniger, löschen) und einer Liste. "mehr" geht nur wenn Einträge in der Liste vorhanden/selektiert, "löschen" genau so und "weniger" geht nur wenn Einträge in Liste vorhanden/selektiert und Anzahl größer 1....Als normale RAD Anwendung einfach, aber wer ist denn nun bei MVVM bzw MVC dafür zuständig die Buttons entsprechend zu de-/aktivieren? View oder ViewModel bzw. Controller oder ...?

Weitere Frage: Für die Anbindung einer View über REST bei MVC gibt es ja nun einige Beispiele z.B. mormot oder DMVC. Wie sieht denn das bei MVVM aus? Kann man dort auch eine View über Rest anbinden? Wenn ja: wie?

Und eine weitere Frage(wenn auch etwas ausserhalb der Delphi Welt): Kennt jemand einen Webshop(natürlich wie immer am liebsten kostenfrei), der sich über Rest an einen Server hängen kann um seine Bestellungen direkt im Server abzusetzen(und der sollte sich am liebsten mit Delphi erstellen lassen...aber das müsste ja wohl z.B. mit DMVC gehen)

Danke schon mal wieder im Voraus für eure hilfreichen Antworten!

[freimatz]

Bitte immer nur ein Thema in einem Beitrag. Danke.
Zu MVVM:
Zuständig die Buttons entsprechend zu de-/aktivieren ist das Viewmodel. Ein Controller gehört da nicht dazu.
Wir machen MVVM mit einem selbstgebauten Framwork. Wegen der schlechten Umsetzung von Generics/RTTI in Delphi kann ich das nicht empfehlen.

[noisy_master]

Zitat von freimatz:

Bitte immer nur ein Thema in einem Beitrag. Danke.

Okay, ich werde versuchen es beim nächsten Mal zu berücksichtigen

Zitat von freimatz:

Zu MVVM:
Zuständig die Buttons entsprechend zu de-/aktivieren ist das Viewmodel. Ein Controller gehört da nicht dazu.
Wir machen MVVM mit einem selbstgebauten Framwork. Wegen der schlechten Umsetzung von Generics/RTTI in Delphi kann ich das nicht empfehlen.

Okay, beim MVC gehört aber ein Controller dazu. Wer macht denn diese Logik bei MVC? Der Controller? Aber der soll doch eigentlich auch nichts vom View "wissen", oder habe ich da was falsch verstanden
Und was kannst du mir nun nicht empfehlen? Das Framework selberzumachen, oder MVVM im allgemeinen? Wenn du MVVM nicht empfehlen kannst: warum macht ihr es dann?
(soll kein "blaming" sein, sondern mich interessiert der technische Hintergrund)

[TheDelphiCoder]

Es gibt auch noch MVP[wikipedia].

[freimatz]

Hallo,
ich kann nicht empfehlen das Framework selber zu machen. Es hat hunderte Stunden gekostet. Wir nehmen es nun halt weil die Zeit eh schon rum ist und wir einigermassen damit klar kommen.
MVVM überhapt zu nehmen weiss ich nicht ob ich das empfehlen soll.
Auf jeden Fall empfehle ich die UI vom Code zu trennen soweit möglich. Da bist du ja dran.
Das ist wichtig um für diesem Code unit tests machen (zu können).
Auch nicht empfehle ich falls Du darüber stolperts etwas was MVVM nennt und auf einem Datenmodul basiert.

Falls Stevie was anbietet - nimm das.
Ausserdem lege ich Dir die Bücher ans Herz:
"Dependency Injection in Delphi"
"Coding in Delphi"
Beide hier

[Stevie]

Zitat von freimatz:

Falls Stevie was anbietet - nimm das.

Danke für die Vorschusslorbeeren, aber an dem Thema hab ich mich schon versucht und es als gescheitert betrachtet - zumindest was eine allgemeingültige Implementierung angeht. Das wird in Delphi einfach nicht rund.
Gerade, wenn es um die verschiedenen UI Controls geht (vor allem Drittanbieter), unterstützen die halt alle nicht einen irgendwie gearteten Mechanismus, um Änderungen an die Binding Engine zu übermitteln. Da muss man dann entweder ableiten oder Interposer Klassen bauen und darauf achten, nicht seine uses Reihenfolge zu verwurschteln.

Wir benutzen eine Mischung aus Binding (die aus DSharp) für simple UI (paar Edits, Checkboxes, etc), VirtualStringTree mit TreeviewPresenter (auch DSharp), DevExpress Grid entweder mit klassischem DataSource/DataSet oder per GridviewPresenter (auch DSharp private Fork Entwicklung) je nachdem, ob die Daten als Objektlisten oder Dataset vorliegen.

Mir fehlt die Zeit, mich erneut in diese Thematik einzuarbeiten, da ich mit Spring4D und einigen anderen Projekten beschäftigt bin, aber inzwischen tendiere ich fast dazu, den DB Aware Component Ansatz zu präferieren (zumindest unter VCL). Durch die Abstraktionsschicht, die ein Dataset bietet, müssen dahinter nicht unbedingt Daten aus einer DB oder so liegen, siehe TObjectDataSet aus Spring4D oder eine nahezu ähnliche Komponente von DevArt (glaub TVirtualDataSet heißt sie). Leider hat man sich bei FMX für die doch arg verwurschtelte LiveBinding Technologie entschieden, wo man erst irgendwelche BindSourceAdapterSchießmichtot Komponenten benötigt, um ein Dataset an die diversen Controls zu binden.

Aber ich fühl mich sowieso im Backend, in der Runtime und bei der Entwickung von Developer Tools wohler als im UI Geraffel

[freimatz]

Hoi, Danke für Deine Antwort.
Ich meine bleib lieber an Spring4D dran, das ist für Delphi wichtiger. (Danke dafür )

Datasets verwenden wir gar nicht. Die DB ist recht tief unten gekapselt mit einem ORM-Mapper.

Wir haben nur eine begrenzte Anzahl von UI-Controils die wir verwenden. Das Binding machten wir dann für jeden Typ dann halt separat.