English version:  @ https://delphiprofi.blogspot.com

Neben einigen Bug-Fixes und den typischen alltäglichen Dingen liegt mein Schwerpunkt nach wie vor auf meinem Delphi-MVVM-Framework.

#D.MVVVM

Warum, weil ich alle meine alten Anwendungen darauf portieren möchte und ich mir vorgenommen habe, kein neues Projekt zu starten, bis das Framework fertig ist, damit ich nicht auf die Idee komme, entweder eine ältere Version davon oder MVVM überhaupt nicht zu verwenden.

Ich habe auch noch den „Traum“, dass ich in der Lage bin, unsere 35 Jahre alte Haupt-VCL – Anwendung von D2007 direkt auf 10.x – #D.MVVM – zu portieren, am besten direkt auf die FMX.

Ich muss also sicherstellen, dass ich das Framework als fertig bezeichnen kann, was bedeutet, dass ich auch die benötigten Funktionen auf den Status „fertig“ setzen muss.

Natürlich, das wissen wir alle: Bei einem solchen Projekt gibt es, wie bei jeder anderen Anwendung auch, niemals den Status „fertig“. Wie finde ich also heraus, ob ich nur noch verbessere? Ok. Zunächst einmal brauche ich eine Feature-Liste. Ich hätte wirklich gerne einen Unit-Test für jedes Feature. Zweitens brauche ich eine ausreichende Dokumentation. (Oh man, das ist ein kritischer Punkt. Ich habe überhaupt keine Dokumentation – bis jetzt).

Aber was ist mit „sauberen“ Source – oder zumindest dem Code (ein bisschen) aufräumen? Ja, das ist auf jeden Fall notwendig.

Wie finden Sie heraus, ob ein Eintrag in der Feature-Liste ein wirklich notwendiges Feature ist und nicht irgendeine nette Funktionalität, die Ich nur hinzufügen wollen? Ich lese wirklich gerne eure Kommentare dazu. Was sind die Kernfunktionen, die eurer Meinung nach in der 1.0 Version, meines Frameworks, enthalten sein muss?

Bevor wir versuchen, einige Funktionen zu sammeln, sollten wir einige Regeln definieren.

Wenn wir eine Anwendung mit dem MVVM-Pattern implementieren wollen wir:

1. Keinen, oder fast keinen Code in der View! Mit Ausnahme von UI-Kram!
2. Vergleicht man eine RAD-App mit einer MVVM-App, so sollte eine MVVM-App genauso einfach zu erstellen sein.
3. Die Bindungen sind das größte Problem, sie müssen so einfach wie möglich einzurichten sein.
4. Keine Verwendung von Anti-Pattern. (Einige Leute nennen eine ViewFactory bereits ein Anti-Pattern)
5. Bestenfalls: Erstellt man einfach beide Arten von „Formularen“, und kann mit derselben Codebasis für VCL oder FMX kompilieren.
6. Jeder Teil unserer Anwendung sollte Unit-testable sein, also keine Abhängigkeiten zwischen den Modulen.
7. Das Schichtenkonzept muss erhalten bleiben.
8. Das Framework sollte ohne die Notwendigkeit des FDK funktionieren. (Ich musste einige Sachen duplizieren)
9. D.MVVM wird als Plugin in das FDK integriert, um von allen fortgeschrittenen Funktionen zu profitieren.
10. Es sollen die visuelle Live-Bindings nicht verwendet werden.
11. Alles sollte funktionieren, ohne nicht-visuelle Komponenten oder spezielle Komponenten auf einem Formular zuklicken.
12. Namenskonventionen werden vor Konfigurationen bevorzugt.
13. Wir kümmern uns nicht darum, wenn ein C#-Entwickler denkt, dass wir alles falsch machen! 

Sonst noch etwas?

Diejenigen die mich kennen wissen, ich klicke nicht gerne Dinge „zusammen“. Ich bevorzuge es, alles im Code zu machen – außer der Form natürlich -, so dass jede Änderung im Quellcode-Repository auftaucht. Vielleicht erstelle ich am Ende einige Komponenten, um den Bedürfnissen der RAD-Entwicklung gerecht zu werden, aber das ist noch nicht entschieden.

Während ich eine Feature-Liste erstelle, kann ich auch einige Tickets erstellen, um den Entwicklungsprozess zu verfolgen.

Mein D.MVVM-Framework sollte enthalten:

1. Einen Assistenten zum Erstellen einer neuen D.MVVM-Anwendung.
2. Einen Assistenten zum Erstellen einer neuen Ansicht (Formular oder Frame).
3. Einen Assistenten zum Erstellen eines neuen ViewModels.
4. Einen Assistenten zum Erstellen eines neuen Modells.
5. Eine Framework (VCL & FMX) unabhängige Ableitung der TForm-Implementierung, um jedem Formular eine Basisfunktionalität zu geben. (fertig)
6. Ein zentraler Punkt für alle Joins oder Viewchains. (fertig)
7. Alle enthaltenen VCL- und FMX-Komponenten sollten bindbar sein.
8. Komponenten von Drittanbietern sollten sich leicht in das Bindungsschema einfügen lassen.
9. Bindungen von der View zum ViewModel sollten möglich sein, ohne eine Zeile Code zu schreiben. (fertig)
10. Bindungen vom ViewModel zum Modell sollten auch ohne jeglichen Code möglich sein. Ein Wertekonverter sollte in den Datentransfer eingebunden werden können. (fertig)
11. Ein Datenkontext sollte die Daten für die Anzeige im Speicher halten. (abgeschlossen, aber nicht vollständig getestet)
12. Einige grundlegende Dienstleistungen sollten enthalten sein. (Action-Service, Navigations-Service, Menü-Service, Dialog-Service, Zeit-Service) 90% erledigt.
13. Ein List-Adapter für den Umgang mit großen Datenmengen für Grids, Listboxen und Memos. (abgeschlossen)
14. Öffentlicher Unit-Test mit 100% Code-Abdeckung. (Einige sind erledigt, aber ich habe die Abdeckung nicht gemessen)
15. VCL- und FMX-Demo-Anwendungen. (einige sind fertig)
16. Dokumentation.

Ich glaube, dies ist noch nicht die endgültige Liste der Version 1.0, aber fast.

Nochmal: Nachdem ich mir Onkel Bobs Lektionen für CleanCode angesehen habe – ich muss einige schwere Refactorings durchführen…

Wenn Ihr irgendwelche Vorschläge für mich haben, würde ich mich sehr über Eure Kommentar zu diesem Thema freuen!

Noch nicht mit dem Thema MVVM beschäftigt? Dann bitte meinen Youtube-Kanal für meine bereits veröffentlichten D.MVVM-Videos anschauen.

Bitte auch meinen Kanal abonnieren und auf die Schaltfläche „Like“ klicken, dies hilft beim Aufbau meines Kanals.

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---