Couche d'abstraction de la base de données et gestion orienté objet des accès aux tables

Soyez le premier à donner votre avis sur cette source.

Vue 10 337 fois - Téléchargée 857 fois

Description

Il s'agit d'un mini-noyau complet pour gérer les accès base de données entièrement en langage objet. La puissance de ce noyau est que lorsque vous souhaitez obtenir l'accès objet à une table, il suffit de créer une classe qui dérive de MyObject pour créer le type de votre table, et une classe qui dérive de MyObjectManager pour créer un gestionnaire d'objets.
Ce noyau est utilisé dans le projet open-source FreeGlobes et est inspiré du noyau d'abstraction de Xoops, ainsi que de certaines routines de la plate-forme de blogs DotClear.
Avec ce mini-noyau vous pouvez :
- Vous pouvez gérer toutes vos tables très simplement avec des méthodes comme getObjects(), deleteAll() ... Toutes les requetes sont gérées par des objets Criteria, inspiré de Xoops
- Proposer un script capable de supporter plusieurs SGBD en écrivant simplement un nouveau driver (le driver MySQL est déjà fait :))
- Logger le nombre de requetes BDD faites
- Instancier vos gestionnaires d'objets par inversion de controle
- Gérer tout vos accès base de données en abstrait : plus aucune requete sql dans votre code métier !

Le code est entièrement commenté pour faciliter sa compréhension. Le code est en PHP4.

Conclusion :


Pour le support sur ces codes sources, je vous invite à venir poster sur le forum de Freeglobes (http://forum.freeglobes.net).

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3
Oh bah je suis content de garder ma propre classe maison ( que j'ai refaite, pas celle qui est ici ^^).

C'est une vrai usine à gaz ton bordel... je comprend que c'est du PHP4 m'enfin quand même :)

Faudra m'expliquer l'intérêt du criteria par contre... Parce que si je décortique le code, ca veut dire que je fou dans un objet ma requète SQL (enfin juste des morceaux apparament), donc un premier parsing; puis ensuite, je redécortique mon objet d'un bout à l'autre pour reconstituer la requète (donc 2ème parsing).
Ca fait pas un peu beaucoup ?

Et puis quel intérêt de faire ca :S Personne ne sait écrire une requète SQL en dur ? :s

Et puis, faudra aussi me démontrer l'intérer de faire une factory si c'est pour ne gérer qu'une seule DB à la fois ! Parce que... ta factory, à part juste servir de Singleton pour ta classe SQL, elle ne sert à rien du tout. Je peux arriver au meme résultat dans une classe unique.

Si tu veux faire de la gestion d'erreur sur tes fonctions mysql_*, met un @.

Bref, y'a un problème d'usine à gaz dans ta factory pour commencer :)
Messages postés
5
Date d'inscription
vendredi 20 mai 2005
Statut
Membre
Dernière intervention
18 décembre 2006

Effectivement, certains fichiers du packages sont issus de xoops (c'est d'ailleurs indiqué dans les sources ;)). Le modele objet a tout de meme été modifié pour supporter le gestionnaire de base de données maison : le modele de xoops ne gerait pas les clef des tables, et toutes les methodes (insert,update,delete...) sont désormais génériques, ce qui n'est pas totalement le cas dans Xoops. (sauf dans xoops 2.2 en derivant de xoopspersistablehandler)

Difficile d'innover pour une abstraction de base de données ! Et le bousin est assez léger tout de meme ;)
Messages postés
1293
Date d'inscription
mardi 9 novembre 2004
Statut
Membre
Dernière intervention
21 mai 2015

Ah la class d'abstraction SGDB de Xoops... bien quelle présente quelques lourdeur c'est ma préférée elle est assez simple à prendre en main mais là ou ça se complique c'est lorsque l'on veux l'utiliser avec la class critéria qui est plus complexe à apréhender... par contre je pense que plutot que te passer par un tableau (déclaré en global je suppose) tu aurais du garder les constantes qui sont bien plus efficace à mon sens (déclarés dans le fichier conf et basta)... .. .

Sinon l'idée est bonne je regrette juste le "manque d'innovation" si je puis dire ça ainsi vu qu'une très grosse partie du package vient de xoops et n'a, à première vue, quasiement pas été modifié... ce qui est domage car certaines parties de ces classes (je pense notament au modèle object de xoops) demande à être retravaillé pour alléger le bousin... cependant ça reste un bon package... .. .

@ tchaOo°
Messages postés
5
Date d'inscription
vendredi 20 mai 2005
Statut
Membre
Dernière intervention
18 décembre 2006

La variable de configuration $CONFIG est dans le fichier conf/config.php. Elle définit le type de base de données ainsi que les informations de connexion à celle-ci.
Messages postés
5
Date d'inscription
vendredi 20 mai 2005
Statut
Membre
Dernière intervention
18 décembre 2006

La seule documentation qu'il y ait pour le moment, c'est les commentaires apportés au code (toutes les fonctions ont une entête aux standards Java) ainsi qu'un fichier exemple reprenant de façon très résumée les possibilités offertes.
Pour ce qui est du passage des informations de la base ça se déroule ainsi :
// instanciation d'un manager d'objets par inversion de controle
$link_m =& get_manager('link');
la fonction get_manager va inclure la classe définissant l'objet link et le manager d'objet link toute seule (suivant des conventions de nommage du fichier classe et des classes dans ce fichier).
dans class.object.php, tu remarqueras que dans le constructeur du manager d'objet nous avons :
$this->con =& DatabaseFactory::getConnection();
Ce code appelle la Factory qui s'occupe de l'instanciation d'une connexion à la base de données. On crée ainsi un découplage entre le type de base de données que l'on veut (SQL, PostGre...) et on laisse l'usine à connexion choisir pour nous le type de connexion approprié en fonction de $CONFIG['database'].
Database::getInstance() fait la meme chose que DatabaseFactory::getConnection();. Ce code est juste Deprecated, je l'utilisais dans un script et je l'ais conservé pour la compatibilité.
La Factory inclut le bon driver de connexion à la base et retourne une instance de celui-ci par inversion de controle suivant $CONFIG['database'] et en lui passant les paramètres de connexion à la base de données.
Le driver de base de données dérive de la classe MyDatabase qui est une interface indiquant les méthodes devant être implémentées dans les sous-classes (dans les drivers).
Afficher les 11 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.