Obwohl das auch nur das Thema ankratzt
Da muss man bei jeder Schicht noch einmal in die Tiefe gehen.
Beispiel
GUI, da gibt es unterschiedliche Ansätze wie MVC, MVVM, ... wobei ich das MVVM besser finde, weil hier beim ViewModel schon der Schnitt von der
GUI erfolgt. Bei MVC kennt der Controller noch die einzelnen Controls und bei Delphi ist somit der Controller auch vom Framework (
VCL, FMX) abhängig und kann daher nur bedingt wiederverwendet werden.
Ein ViewModel ist also nur eine Brücke zwischen der UI und dem Rest der Anwendung.
Der Einstieg zum ViewModel mit Delphi wird auch nicht unbedingt leicht gemacht. Viele benötigte und hilfreiche Strukturen sind schon mal gar nicht vorhanden und müssen erst aufgebaut werden.
- MultiCast-Events (nein, die Spring4D-Variante finde ich nicht gelungen) (*)
- ObservableCollection (s.o.)
- ICommand, RelayCommand
- ...
Wenn man das hinter sich hat, dann wird es schon einfacher, aber der Weg ist zunächst steinig.
Auch das fehlende ARC für den Desktop-Bereich steht bei solchen Lösungen teilweise im Weg.
(*) Spring4D lehnt sich ja sehr stark an Visual-C#/.Net an stolpert aber über den unbedingten Willen, das zu 100% Delphi-Event-kompatibel zu machen - was ich persönlich für überflüssig halte - und einige Stellen sind daher nicht mit nativem Delphi-Code zu realisieren wodurch die Portierbarkeit (Android, iOS, OSX) leidet.
Bei .Net sind alle Events gleich aufgebaut mit einem Sender und einem EventArgument. Wenn man das genau so in Delphi umsetzt, dann braucht man das Gefrickel nicht und kommt mit reinem, portierbarem Delphi-Code klar.
Die ObservableCollection in Spring4D feuert bei jeder
einzelnen Änderung ein Event (z.B. eine Collection mit 1000 Items feuert bei Clear 1000 Events - eben so wie Delphi das eben macht) wo bei .Net genau
ein Event gefeuert wird und beinhaltet u.a. eine Liste mit OldItems, die in diesem Fall eben diese 1000 Items enthalten. Wenn man das UI damit steuert, kann man sich schon ausrechnen, was da besser ist/wäre
