Konfiguration des OR-Mappers

Anmerkungen, Fragen und Hinweise zur Konfiguration dürfen in diesem Forum gepostet werden. // Notes, questions, and hints on the configuration can be posted here.
Antworten
Benutzeravatar
Manko10
Beiträge: 73
Registriert: 16.11.2009, 21:46:58
Kontaktdaten:

Konfiguration des OR-Mappers

Beitrag von Manko10 » 16.11.2009, 22:18:32

Hallo,

derzeit bin ich dabei, mich in das APF einzuarbeiten und stecke derzeit beim genereischen OR-Mapper wie er hier beschrieben ist: http://adventure-php-framework.org/Seit ... -OR-Mapper
Der Mapper gefällt mir auf den ersten Blick schon sehr gut, doch habe ich mich dann gefragt, weshalb die Beziehungen über INI-Konfigurationen geregelt werden und nicht über Objekte.
Ich könnte mir auch durchaus Konfigurationen dieser Art vorstellen:

Code: Alles auswählen

class MyTable
{
    public static $vars = array(
        'MyVar' => 'VARCHAR(200)'
    );
    public static $has_many = array(
        'Bla' => 'YourTable',
        'Type' => 'COMPOSITION'
    );
}

class YourTable
{
    public static $vars = array(
        'YourVar' => 'INT'
    );
    public static $has_one = array(
        'Blub' => 'MyTable'
    );
}
Oder verstöße das gegen die Paradigmen des APF? Für mich persönlich ist diese Art der „Konfiguration“ etwas intuitiver, auch wenn man hier vielleicht noch ein wenig herumdenken müsste, bis man die Typen Komposition und Assoziation sinnvoll unterbekommt (ich habe die hier einfach nur so reingeschummelt).
Auch wenn bei dieser Art öffentliche Eigenschaften verwendet werden, so lassen sich doch leicht 1:1 (has_one:has_one), 1:n (has_many:has_one) und n:m (many_many:belongs_many_many) nach Vorbild des sapphire-Frameworks aus dem Silverstripe-CMS abbilden ohne dafür auf INI-Dateien angewiesen zu sein, die ich persönlich immer als sehr unschön empfinde.
Hat das aber vielleicht einen speziellen Grund, weshalb hier INI-Files verwendet werden und keine Klassen bzw. Objekte?
Visit Refining Linux for taking your Linux to the next level.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: Konfiguration des OR-Mappers

Beitrag von dr.e. » 16.11.2009, 23:50:00

Hallo Manko10,

nice too meet you here! 8-)
Der Mapper gefällt mir auf den ersten Blick schon sehr gut, doch habe ich mich dann gefragt, weshalb die Beziehungen über INI-Konfigurationen geregelt werden und nicht über Objekte.
Das ist einerseits ein Paradigma des APF (INI-Konfigurationen), andererseits ist es eine sehr einfache Möglichkeit, mehrdimensionale Beziehungs-Graphen in einer flachen Konfiguration abzubilden. Weiterhin bin ich persönlich überzeugt, dass das INI-Format eine gute Symbiose aus Einfachheit und Wartbarkeit bietet und sehr einfach zu parsen ist. Gerade das Thema Performance ist mir sehr am Herzen gelegen, was sich in den aktuellen Benchmarks wiederspiegelt.
Ich könnte mir auch durchaus Konfigurationen dieser Art vorstellen:
Das ist konzeptionell ebenfalls denkbar. Frameworks wie CakePHP oder CodeIgniter nutzen diese Art der Definition um Datenstrukturen abzubilden. Der GenericORMapper geht einen anderen Weg. Er verfolgt den Ansatz, dass ein Data-Mapper nahezu bei jeder Implementierung gleichartige Aufgaben erledigt, die generisch abbildbar sein. Die variablen Anteile - sprich die Domänen-Objekte einer Anwendung - können dabei konfiguriert werden. Das Konzept möchte erreichen, möglichst wenig Code einer Datenschicht selbst schreiben zu müssen. Wie das Usermanagement-Modul des APF zeigt, ist mit dem GORM die Implementierung der Datenschicht praktisch gegessen. Sofern es erwünscht ist, kann das nach wie vor stattfinden (siehe Gästebuch in der Version 2009 im SVN - Artikel folgen in Kürze), muss aber nicht sein.

CakePHP & Co. (miss-)interpretieren meiner Ansicht nach auch das MVC-Pattern etwas und nutzen das Model als Datenschicht. Das ist nur bedingt korrekt und führt immer wieder zu Problemen in der Abbildung einer komplexen Domänen-Struktur, in der Beziehungen eine wichtige Rolle spielen. Hierzu gab es ja im PHP.de-Forum bereits einschlägige Diskussionen. Da das APF auf das 3-Schicht-Architektur-Pattern in Verbindung mit HMVC als strategische Pattern setzt (neben Page- und Front-Controller im Bereich der Front-End-Entwicklung), ist es nur allzu konsequent, einen generischen Ansatz für das Erstellen und Verwalten einer Domänen-Struktur anzubieten.
Oder verstöße das gegen die Paradigmen des APF? Für mich persönlich ist diese Art der „Konfiguration“ etwas intuitiver, auch wenn man hier vielleicht noch ein wenig herumdenken müsste, bis man die Typen Komposition und Assoziation sinnvoll unterbekommt (ich habe die hier einfach nur so reingeschummelt).
Wie angedeutet, ist das hinsichtlich des GORM ein Paradigmen-Wechsel. Ich würde nicht sagen Verstoß, denn du bist im APF nach wie vor frei andere OR-Mapper zu nutzen (Doctrine, ...) oder deinen eigenen Mapper zu schreiben. Sofern du den GORM ein paar mal eingesetzt hast, ist die Vorgehensweise auch "intuitiv", denn du kommst dabei einfach von einer anderen Seite - dem OO-Design. Das APF "besteht" darauf, dass du ein sauberes Software-Design erstellst und dann die Implementierung beginnst. Startest du wie beim Artikel Objektorientiertes Design eines Gästebuchs mit dem Domänen-Modell, das aus Objekten und deren Beziehungen besteht - die für sich und gemeinsam genommen eine Bedeutung für deine Applikation besitzen -, so ist es ein Kinderspiel, das UML in die jeweiligen Konfigurationen zu übersetzten. Da der XMI-Export vieler Tools noch nicht so ausgereift ist, gibt es noch kein sinnvolles Tool zur Generierung der Configs aus dem UML, das ist aber angedacht. Da das APF grundsätzlich von deutlich höherer Komplexität als die meisten Frameworks ausgeht, ist das IMHO sehr intuitiv.
In der von dir skizzierten Art und Weise lassen sich Komposition und Assoziation nicht ganz so einfach abbilden, da du innerhalb des Objektes die Abhängigkeiten/Auswirkungen der Deklaration einer Beziehung des Typs Komposition und Assoziation berücksichtigen musst. Da auch das generisch abbildbar ist, sollte es konsequenterweise ausgelagert werden. Spinnt man dies weiter, so landest du meiner Ansicht nach immer beim GORM - sofern du komplexere Domänen-Objekte betrachtest. Für Anwendungen mit einem Domänen-Objekt ist das sicher nicht notwendig.
Auch wenn bei dieser Art öffentliche Eigenschaften verwendet werden, so lassen sich doch leicht 1:1 (has_one:has_one), 1:n (has_many:has_one) und n:m (many_many:belongs_many_many) nach Vorbild des sapphire-Frameworks aus dem Silverstripe-CMS abbilden ohne dafür auf INI-Dateien angewiesen zu sein, die ich persönlich immer als sehr unschön empfinde.
Hat das aber vielleicht einen speziellen Grund, weshalb hier INI-Files verwendet werden und keine Klassen bzw. Objekte?
Ich denke, obige Anmerkungen beantworten das. Es ist einfach eine Frage der Herangehensweise. Ausgehend von einem UML ist es sehr einfach Konfigurationen und Klassen gleichermaßen zu generieren. Ein Roundtrip ist zwar eher schwierig, aber warum soll ich mir 1000 Klassen mit einem Skript generieren, wenn es mit einer einzigen generischen Implementierung erschlagen ist? Ein weiterer Entscheidungs-Grund für INI-Files ist die schlanke Struktur. Auch be komplexen Struktren bin ich bisher nie an die Grenzen gestossen. Sie lassen sich leicht parsen, schreiben, editieren, ...

Gegenfrage: hattest du bisher Schwierigkeiten mit dem Einstieg? Hat dir etwas gefehlt?
Viele Grüße,
Christian

Benutzeravatar
Manko10
Beiträge: 73
Registriert: 16.11.2009, 21:46:58
Kontaktdaten:

Re: Konfiguration des OR-Mappers

Beitrag von Manko10 » 17.11.2009, 00:14:25

CakePHP & Co. (miss-)interpretieren meiner Ansicht nach auch das MVC-Pattern etwas und nutzen das Model als Datenschicht.
Ja, das ist mir auch schon aufgefallen. Im sapphire-Framework, von dem ich mich da inspirieren ließ, wird auch das Model als Datenschicht und der Controller als Domänenschicht angesehen, was dann aber hieße, dass MVC gleichbedeutend einer dreischichtigen Architektur ist und in dem Falle kein Pattern der Präsentationsschicht mit Überhang in die Domänenschicht.

Warum du INI-Files genutzt hast, ist mir schon klar und dass das performanter und weniger Code ist, ist ebenfalls klar. Ich bin nur immer nicht so sehr angetan von herkömmlichen Einstellungsdateien und stehe eher auf Konvention denn auf Konfiguration. Nach Konventionen erstellte Klassen finde ich daher meist eleganter. Aber vielleicht ist das auch eine Gewöhnungssache.
Gegenfrage: hattest du bisher Schwierigkeiten mit dem Einstieg? Hat dir etwas gefehlt?
Da ich noch sehr am Anfang stehe und noch nicht wirklich tief eingestiegen bin, kann ich die Frage noch nicht wirklich beantworten. Aus dem Stegreif kann ich aber sagen, dass das APF auf jeden Fall mehr Dokumentation braucht, aber wie ich dir gegenüber irgendwann schon einmal erwähnte, überlege ich, sofern ich das APF für eigene Projekte einsetzen werde, eine Art „APF Documentation Project“ ins Leben zu rufen, um die Dokumentation auf hohem und vielschichtigem Niveau voranzutreiben. Die derzeitige Dokumentation ist sehr auf die technische Seite ausgelegt. Das APF ist zwar auch in erster Linie hierauf ausgerichtet, jedoch bekommt der Anwender hiervon hinterher absolut nichts mit, weshalb es wichtig wäre, auch mehr auf das Design von GUIs einzugehen, was durch die DOM-Struktur ja sehr gut möglich ist, und vielleicht sogar Paradigmen zur agilen Softwareentwicklung mit dem APF zu entwickeln, sofern das ohne Umstände möglich ist und keinen unnötigen Philosophiewechsel erfordert.
Ohne den bisherigen guten Einstieg in die Dokumentation herabwürdigen zu wollen, bin ich doch der Meinung, dass eine gute Dokumentation deutlich mehr ist, als bloß eine Handvoll guter Tutorials und Referenzen der Engineers-Seite. :-)


EDIT:
Zu den INI-Files: ich hoffe doch, du parst sie nicht mit parse_ini_file(), der Funktion, die wohl den Titel „Buggiest PHP function ever“ verdient? ;-)

EDIT2:
Owei, doch:

Code: Alles auswählen

00328       private function __loadConfiguration($namespace,$context,$configName){
00329          $configFile = $this->__getConfigurationFileName($namespace,$context,$configName);
00330          return parse_ini_file($configFile,true);
00331        // end function
00332       }
Visit Refining Linux for taking your Linux to the next level.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: Konfiguration des OR-Mappers

Beitrag von dr.e. » 17.11.2009, 13:10:35

Hallo Manko10,
Aus dem Stegreif kann ich aber sagen, dass das APF auf jeden Fall mehr Dokumentation braucht, aber wie ich dir gegenüber irgendwann schon einmal erwähnte, überlege ich, sofern ich das APF für eigene Projekte einsetzen werde, eine Art „APF Documentation Project“ ins Leben zu rufen, um die Dokumentation auf hohem und vielschichtigem Niveau voranzutreiben.
Korrekt, die Dokumentation steht anderen Projekten nach. Ein Dokumentations-Projekt ist eine sehr gute Idee. Vielleicht könnte man das auch im Rahmen eines WIKI oder Blogs auf eine technische Basis stellen, die die Mitarbeit von mehreren Leuten ermöglicht.
Die derzeitige Dokumentation ist sehr auf die technische Seite ausgelegt. Das APF ist zwar auch in erster Linie hierauf ausgerichtet, jedoch bekommt der Anwender hiervon hinterher absolut nichts mit, weshalb es wichtig wäre, auch mehr auf das Design von GUIs einzugehen, was durch die DOM-Struktur ja sehr gut möglich ist, und vielleicht sogar Paradigmen zur agilen Softwareentwicklung mit dem APF zu entwickeln, sofern das ohne Umstände möglich ist und keinen unnötigen Philosophiewechsel erfordert.
Ich denke nicht, dass agile Entwicklung und das APF im Gegensatz stehen. Gerade die generischen Ansätze des APF sollten es erlauben, agile Entwicklung zu betreiben.
Zu den INI-Files: ich hoffe doch, du parst sie nicht mit parse_ini_file(), der Funktion, die wohl den Titel „Buggiest PHP function ever“ verdient? ;-)
Ich habe Performance-Tests durchgeführt und jeder Versuch das manuell schneller zu parsen sind schief gegangen. Bisher hatte ich bis auf ein Thema auch keine Probleme mit der Verarbeitung.
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Konfiguration des OR-Mappers

Beitrag von Megger » 17.11.2009, 16:41:33

Hiho

Also in Bezug auf agile Softwareentwicklung kann man das APF sehr gut einsetzen. Durch den generischen Ansatz kann man sehr gut nebeneinander programmieren und an verschiedenen Stellen arbeiten, die trotzdem aufeinander zugreifen.
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
Manko10
Beiträge: 73
Registriert: 16.11.2009, 21:46:58
Kontaktdaten:

Re: Konfiguration des OR-Mappers

Beitrag von Manko10 » 17.11.2009, 16:56:44

Bisher hatte ich bis auf ein Thema auch keine Probleme mit der Verarbeitung.
parse_ini_file() ist wie unser Board auf php.de: bei einigen Zeichen wird alles Nachkommende abgeschnitten. Eines der Zeichen ist z.B. die Tilde ~. In den User-Contributed-Notes auf php.net sollten noch weitere Bugs stehen. Performancetechnisch ist parse_ini_file() natürlich unschlagbar, da sie in C implementiert ist, das ist aber auch der einzige Gesichtspunkt, der gegen eine Eigenimplementierung spräche.
Ich denke nicht, dass agile Entwicklung und das APF im Gegensatz stehen. Gerade die generischen Ansätze des APF sollten es erlauben, agile Entwicklung zu betreiben.
Also in Bezug auf agile Softwareentwicklung kann man das APF sehr gut einsetzen. Durch den generischen Ansatz kann man sehr gut nebeneinander programmieren und an verschiedenen Stellen arbeiten, die trotzdem aufeinander zugreifen.
Klingt gut!
Ich werde mich mal etwas tiefer einarbeiten.
Visit Refining Linux for taking your Linux to the next level.

Benutzeravatar
Manko10
Beiträge: 73
Registriert: 16.11.2009, 21:46:58
Kontaktdaten:

Re: Konfiguration des OR-Mappers

Beitrag von Manko10 » 17.11.2009, 17:47:39

Nachtrag:
laut php.net soll die Tilde innerhalb von "..." funktionieren. So weit ich mich erinnere, trat das Problem aber auch damit auf. naja, vielleicht ist das ja jetzt behoben. Seit einiger Zeit steht da auch ein Zusatz:
Note: There are reserved words which must not be used as keys for ini files. These include: null, yes, no, true, false, on, off, none. Values null, no and false results in "", yes and true results in "1". Characters {}|&~![()^" must not be used anywhere in the key and have a special meaning in the value.
Nur welche Bedeutung die Zeichen haben, steht da nicht. Wahrscheinlich wurden hier erfolgreich Bugs als Features deklariert.
Visit Refining Linux for taking your Linux to the next level.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: Konfiguration des OR-Mappers

Beitrag von dr.e. » 17.11.2009, 18:40:04

Hallo Manko,

das ist natürlich unerfreulich, die Performance geht jedoch vor. :)

Was die Implementierung des GORM angeht, so findest du unter http://media.adventure-php-framework.or ... ierung.pdf einen noch nicht veröffentlichten Artikel, der sicher ein paar wertvolle Hinweise enthält. Dieser wird demnächst (=mit der Version 1.11) noch in diesem Jahr erscheinen.

Weil wir gerade beim Thema Dokumentation sind: was hälst du von den o.a. Vorschlägen?
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast