So, ich hab mir das jetzt auch mal angeschaut - bin ich blind oder wo ist der Source Code?
Ich mein, nix gegen deine Videos, aber wo kann man das selber ausprobieren? Ich hab immer nen Problem, wenn mir jemand, der was programmiert hat, vorführt, wie doll das alles funktioniert, ohne dass ich es selber auf Herz und Nieren prüfen kann. Ist mir schon oft passiert - bei der Präsentation alle staunend da gesessen und hinterher geflucht, wenn mans selber benutzen musste. (nein, ich meine nicht FireMonkey
)
Ich wollte erst einmal grundsätzlich sehen, was Ihr von der Lösung haltet. In der Form kannte ich bisher noch kein Framework.
Ich selbst komme mit dem aktuellen Stand schon sehr gut zurecht - geht aber vermutlich jedem Entwickler so
Wenn ein breiteres Interesse bestanden hätte, hätte man natürlich noch einiges an der Benutzbarkeit optimieren können. So erweitere ich die Klassen nach und nach entsprechend Notwendigkeit und verfügbarer Zeit.
Ich schicke Dir mal einen Link zu einer Testversion per pn. Es gibt aber noch keinen Installer und keine Hilfe und es kann an einigen Stellen schon noch etwas hakeln.
In den Videobeispielen zu School-Projekt (
Beitrag #6) sind die notwendigen Schritte erklärt. Es ist nicht sehr kompliziert, aber ein paar Dinge sind natürlich zu beachten.
Zum Experten teile ich die Meinung von mquadrat. Da hätt ich auch den Interface Teil einer
Unit schreiben können und der Experte erzeugt mir den Implementation Teil. Auch das Format scheint mir etwas eigenwillig.
Die Meinung teile ich inzwischen auch. Ich plane deshalb durchaus einen Editor, in dem man Klassen und Typen z.B. per ComboBox auswählen kann. Das wäre schon noch deutlich komfortabler, aber es geht erstmal auch mit dem Texteditor ganz gut. Einen
UML-Designer plane ich definitiv nicht. Erstens wäre das zu aufwendig und ich will den die Klassendeklaration außerdem möglichst nah am Aufbau der zu erzeugenden Units halten.
Die cla-Datei stellt somit eine Übersicht über die erzeugten Units dar, allerdings nur auf die Daten bezogen.
Da die erzeugten Units auch die kompletten Referenzen der Datenobjekte aufeinander realisieren, würdest Du mit dem schreiben des interface-Teils nicht weit kommen. Der odExperte übernimmt da noch einiges mehr.
Schau dir mal ModelMaker an, damit kann man sowas auch machen, eventuell gibt das noch die eine oder andere Idee.
Das stimmt. Wenn ich den gekannt hätte, hätte ich es vielleicht auch einmal damit versucht. Allerdings kann ich nicht wirklich beurteilen, wie flexibel das Ganze ist. Lassen sich die Klassen denn problemlos mit beliebigen Funktionen und Prozeduren erweitern und vor allem auch debuggen? Vielleicht teste ich das später einmal.
Meine Lösung ist natürlich optisch nicht so aufwendig, dafür lassen sich die erzeugten Klassen sehr flexibel erweitern und verändern.
Dazu ist das Speichern und Laden automatisch implementiert und es gibt eine Datenbindung an die Formulare (wobei es dafür natürlich nun auch andere Lösungen gibt).
Die Controls an sich find ich prima. Allerdings erschließt sich mir noch nicht ganz, wie weit sie in das ganze System verflochten sind.
Was meinst Du? Ich nutze statt einem TEdit ein TodEdit usw. Die odControls enthalten ein TodDataSet, das eine Datenkomponente und den gewünschten PropertyName zugewiesen bekommt.
Die odDataSets werden über Änderungen in der Datenschicht informiert und veranlassen ihren Owner, sich neu zu zeichnen. Sicher könntest Du das noch geschickter lösen.
Den Tree zum Auswählen der Eigenschaften find ich auch gut (muss ich mal in meine Bindings einbauen *g*). Woran macht er fest, welche Eigenschaften angezeigt werden? Nur die mit den Attributen?
Genau.
Ein bisschen flau wurde mir ehrlich gesagt bei der Turnier Klasse, das sah mir sehr nach god object aus, in dem alles drin steckt.
Würde ich nicht so sagen. Das TournamentEvent-Objekt kennt die Sportart, den Ort und die Turniere und kann mit diesen umgehen.
Die genannten Objekte selbst haben wieder ihre eigenen Unterobjekte und eine eigene Geschäftslogik. Das ist doch ok, oder?
Bei der Generierung der Klassen musste ich an
code first denken.
Weiß nicht recht, kann sein...