Discussion :

[Benjamin Delespierre]

Bonsoir à tous.

Je suis en train de réfléchir à une architecture objet me permettant de faire de la réflexion d'une base de données MySQL. L'idée est de pouvoir fournir aux couches métier et présentation un visuel sur l'état de la base de données tant en termes de structure que de données. Ne me demandez pas pourquoi, on dira simplement que je travaille dans un contexte ou je n'ai pas le contrôle sur les base de données avec lesquelles travaillent mon application.
Actuellement, si on prends le cas d'école "produit", je dispose d'un modèle sous forme de classe Product, d'un métier ProductManager, d'un agrégateur Products, d'un contrôleur ProductsController et de plusieurs templates de vues (edit, list et view). Le problème est que (trop) souvent, d'autres développeurs dont les application adressent également les bases de données changent le schéma, ce qui à pour incidence de revisiter une bonne partie des classes sus-nommées.
Là ou je souhaite arriver c'est fournir un composant capable de faire de la réflexion sur les tables, les vues, les procédures et les databases - c'est à dire d'en connaitre le schéma, les intrications entre les entités, les relations etc.

La définition des besoins fait apparaître la nécessité de reproduire le mécanisme des Reflector de PHP 5. Ma question est alors la suivante:
est-il envisageable d'écrire une série de classes qui réalisent l'interface Reflector ?

ORM et Frameworks s'abstenir, je n'en veux pas.

[stealth35]

oui ça me semble faisable, y'a moyen de faire quelque chose de bien en plus
par contre certaines info dépendent des SGBD et des droits dessus

[Benjamin Delespierre]

Je n'ai pas trouvé grand chose sur Google à ce sujet (je suis d'ailleurs tombé sur mon propre topic avec les mots clés "php database reflector" ). Il me semble que des framework de test comme PHPUnit utilisent une technologie comparable, on pourrait sûrement s'inspirer de leur fonctionnement.

Enfin ma question n'était pas tant de l'ordre de la faisabilité - en réalité, j'ai déjà quelques ébauches de classes service capable de renvoyer une structure de table, de générer des requêtes et d'extraire les valeurs par défaut d'une table, ça marche assez bien soit dit en passant - mais plutôt d'un ordre logique: est ce que le prendre comme ça, c'est à dire étendre le mécanisme de réflexion de PHP, est une bonne ou mauvaise approche.

Le but avoué est la génération de vues et de formulaires "à la volée", les plus malins l'auront deviné, je travaille sur des back-offices écrits en PHP

par contre certaines info dépendent des SGBD et des droits dessus

Tout à fait, mais la problématique est assez complexe comme ça sans devoir ajouter une couche d'abstraction (même si je vois déjà à quoi elle va ressembler). Je souhaite me concentrer sur MySQL, ensuite il sera toujours possible d'étendre en factorisant et en mettant des adaptateur partout.

[stealth35]

Je trouve que c'est une bonne idée.

[Benjamin Delespierre]

Je constate que l'interface Reflector définit une méthode statique export. Dans le contexte de ReflectionClass, ça permet d'exporter la classe visiblement. Je ne comprends pas bien ce que cela signifie et comment l'implémenter dans mon cas.
Auriez-vous des idées là dessus ?

[stealth35]

oui Reflector c'est pour le rendre en texte, mais rien n'empeche d'avoir les valeurs

ReflectionClass -> getMethods -> ReflectionMethod -> isPublic

donc niveau table tu peux avoir par exemple

ReflectionBase -> getTables -> ReflectionTable -> getEngine