So, ich hab mir die Videos jetzt mal angeschaut und würde meine Bemerkungen dann auch wieder aufteilen wollen:
Experte / Code Generation
Der Experte hat
IMHO zwei Nachteile. Erstens hat man innerhalb des Experten, also beim Definieren der Metadaten, keinerlei Hilfen. Man kann sich also beliebig vertippen. Hier wären ggf. Tabellen zum Ausfüllen, in denen man über ComboBoxen die Typen auswählen kann, besser geeignet. Desweiteren macht man eine Programmierung in der Programmierung auf. Das ist ein klassischer Fall von "Ist-Halt-So" und konzeptbedingt.
Wenn man schon ein Modell der Daten aufbaut, dann könnte man weitere Metadaten integrieren. Ich denke da an Maximallängen für Strings, Reguläre Ausdrücke, denen die Einträge entsprechen müssen oder auch die Kennzeichnung von Pflichtangaben (not null). Bis auf die regulären Ausdrücke brauchst du das sowieso, wenn du später mal per Forware Engineering die passenden Datentabellen in einem RDBMS erzeugen willst.
Die Code-Generierung sieht ganz gut auch das Reagieren auf verwänderten Source-Code. Wobei man eine Option anbieten sollte, dass veränderte Getter/Setter so beibehalten werden wie sie sind. Wenn ich mir große Klassen vorstelle, die mir jeden Getter / Setter um die Ohren hauen, den ich verändert habe, nur weil ein neues Feld dazu gekommen ist, dann verliert man schnell die Lust.
Ach ja und für meinen Geschmack sind es etwas arg viele Regionen
Was ich jetzt noch als offene Frage hätte, wäre wie man mit Fremdunits umgeht. Also beispielweise mit Klassen, die vom
WSDL Importer von Delphi erstellt wurden und zur Kommunikation mit Webservices dienen. Müsste man die Strukturen duplizieren und einen Adapter schreiben? Oder kann man die dem Datenmodell irgendwie "unterschieben"?
Datenbindung und Controls
Den TreeView für die Datenbindung finde ich sehr schick. Da kann man schön durchnavigieren. Nun bin ich ja aber ein Fan des ViewModels, also eines Modells je View (wie der Name sagt
). Das fehlt mir so ein bisschen. Sicher kann man einen Teil der Validierungslogik über zusätzliche Metadaten (siehe Punkt 1) abfangen, möchte ich aber beispielsweise eine Funktion nur dann erlauben wenn in zwei Feldern eine Kombination aus bestimmten Werten steht, dann müsste ich das wieder in das Form bzw. einen neuen zusätzlichen Controller packen. Da dein Konzept aber ja ein anderes ist, kann man das den Komponenten nicht vorwerfen
Was die Controls angeht hat man ja prinzipiell zwei Möglichkeiten: Entweder ich vererbe neue Controls (so wie du) oder ich erstelle Adapter, die die Bindung an die Controls übernehmen. Mit den Adaptern ist man, wie ich finde, flexibler. Man kann natürlicha auch beides mischen.
App-Framework insgesamt
Nun hat man zwar keine Implementierung gesehen, aber rein vom Gefühl würde ich sagen, dass teilweise zu viel in den Framework-Klassen passiert. Der Experte scheint mir für zu viel zuständig zu sein. Solltest du das intern über viele kleine und leichtgewichtige Klassen gelöst haben, die du nach außen versteckst, dann gilt mein Argument natürlich nicht
Die Funktionsweise der File-Klasse ist mir noch nicht so ganz klar. Serialisiert die die Daten selber oder fordert die die Daten auf sich selbst zu serialisieren? Auch hier wären ggf. Adapter interessant um verschiedene Persistierungsarten zu ermöglichen.
Ich habe übrigens absichtlich App-Framework geschrieben. Du hast einen Experten, der über ein Modell der Daten Code generiert. Du hast eigene Controls. Wenn du jetzt noch etwas mehr Handling für das Application Lifecycle integrierst, dann hast du im Grunde ein eigenes App-Framework gebaut. Was noch schön zum Konzept passen würde, wäre das Anbieten einer Reihe von Services (Mailversand, oder, oder, oder), die du zur Verfügung stellts. Ergo, alles was außerhalb der eigentlichen Geschäftslogik vor sich geht.
So, das mal als ersten Eindruck.