Structure schématique pour une couche d'abstraction SGBD

Bonsoir/Bonjour à vous tous

Voila, je suis quelque peu en galère.
J'aimerai me faire ma propre classe Database qui implémenterai n'importe quelle interface derriere (MySQL, MsSQL, etc).
Par contre je bloque sur un soucis de structuration.
J'essaye de faire en sorte que ma classe soit la plus propre possible pour pouvoir etre évolutive sans trop gener les classes dépendantes.

Voila ce qu'il en est
J'ai
_ une classe abstraite qui contient les fonctions connect, select_db, close, query, num_row, fetch, fetch_all
_ une classe DBiterators qui contient les next, current, prev, valid, key, seek, count et consor
_ une classe MySQL qui étends la classe abstraite pour les fonctions connect, close, etc


Ce que j'aimerai, c'est que ma classe abstraite soit découpé en plusieurs parties (deux exactement)
_ Une classe (abstraite) AbstractMainDB (connect, close, select_db, last_error)
_ Une classe (abstraite) AbstractActionDB (query, prepare, execute, fetch, fetch_all)

Mais il y a autre chose, j'aimerai que ma classe DBIterators soit liée à ma classe Main.

L'idée serait que la classe MySQL étendrais AbstractMainDB, tout en puissant utiliser les fonctionnalitées additionnelles de AbstractActionDB.
La classe AbstractActionDB quant à elle serait en liaison avec la classe DBIterators.

Est-ce possible de lier tout ca sans faire passer les instances en variable dans les différentes classes.

La seule solution que j'ai trouvé serait de faire une classe abstraite DBIterators, une classe abstraite AbstractMainDB qui étends la classe DBIterators et la classe AbstractActionDB qui étends la classe AbstractMainDB. La classe MySQL quant à elle étendrait la classe AbstractActionDB

Mais voila, j'étends la classe AbstractActionDB au lieu de DBMain, et DBIterator se situe au dessus de AbstractMainDB alors que logiquement (ce que je trouverai logique :p), elle devrait se trouver entre AbstractMainDB et AbstractActionDB.

J'espere avoir été assez clair

Merci beaucoup de votre aide !!

Hello,

je ne vais pas te répondre directement parce que c'est à toi de trouver la structure qui te plait. Je vais juste t'aiguiller : tu réflêchis trop linéairement. Tu veux faire ça :
O -> O -> O -> O
Alors qu'il y a tellement de façons de faire très différentes ;-)
Tu devrais jeter un oeil sur mes nouveaux tuto, je pense qu tu y découvriras quelques façons d'organiser les objets auxquelles tu n'avais pas songées, là, apparemment.
Un objet peut en cacher un autre... : en php, on a parfois des trucs de ce genre :
obj -> method() -> newobj -> newmethod() (je schématise).

hum, ok je vais voir tes différents tutoriaux, mais pour l'instant, je ne vois toujours pas trop comment faire :p

J'ai une proposition à te faire.
Je te dit ce que j'aurai comme solution, et tu me dit si c'est correct, ou au contraire si ca tient pas debout.
Car je viens de regarder tes deux tutoriaux sur les designs pattern, et j'ai un peu du mal !! :p

Le soucis c'est que j'arrive vraiment pas a voir comment faire.

Est-ce que je devrais faire un truc du genre :

$monObj = new MaClassMain (new MaClassAction); ?
mais je sais pa trop comment implémenter la classe SPL !

tu peux me donner plus d'indices ? (chuis d'accord pour ne pas tout me dire, ce serait trop facil, et c'est pas interessant, mais là, je patoge encore trop :/)

merci de ton aide ! :)

Bon, apres lecture, re-lecture, re-re-lecture et encore rerererelecture de tes deux tutoriaux sur les designs pattern, je suppose, mais alors sans absolument aucune certitude, que la partie qui me concernerait, serait celle du Builder ? (partie 1 de tes tutos)

J'ai vraiment du mal a me concevoir le code dans ma tete par rapport à ce que je veux faire.
Tu pourrais m'en dire plus  s'il te plait ?

Merci

Salut,
le principal protagoniste étant ici, je pense que la meilleure source à ce sujet reste celle-ci: http://www.phpcs.com/codes/PHP5-ABSTRACTION-BDD-STYLE-PDO-AVEC-ITERATEURS-TRANSACTIONS_42818.aspx
Comme toi, j'étais confronté aux problèmes de design concernant l'abstraction SGDB mais aprés plusieurs essais je suis retombé sur la même structure que la source présentée ci-dessous. Si j'ai un conseil à te donner c'est d'y jeter un coup d'oeil.

en fait j'ai deja pas mal potassé cette source, a vrai dire, je l'ai meme faite et refaite, mais j'aimerai bien tenter mon coup histoire de comprendre vraiment les design pattern sans recopier un code (je ne dit pas que tu l'a recopié ! ;) ).
Sa source est interessante, mais j'aimerai essayer la mienne :) si ca ne pose pas de problemes :p

Mais merci quand meme de ton lien et de l'interet que tu porte à vouloir m'aider :)

Merci ;-)

J'ai pas franchement le temps. Mais mon idée : je ne veux pas t'expliquer clairement des trucs parce que tout le bonheur de la POO c'est bien de modéliser ses packages ;-) Donc je veux que tu trouves TA solution.
Mais...tu veux séparer l'action de la "connection". Ok pourquoi pas, c'est pas nouveau. Au fond, pourquoi ta classe action ne serait pas renvoyée par une classe de plus haut niveau ? J'instancie une classe X, je fais une connecxon, une requête...la requête renvoie un objet de type "action", avec qui je peux parcourir le résultat de ma requête. Un peu façon PDO. Dans ce cas, tu dois revoir ta façon linéaire de réflêchir ton code.
Tu peux aussi t'appuyser un peu sur le DECORATOR, en suivant mon code, ou celui du BUILDER...éventuellement. Et évidemment, en mixer plusieurs...
Tu peux avoir un objet qui choisit l'objet à utiliser en fonction du contexte, au seins d'une collection de petits objets dédiés (à la façon du STRATEGY pattern).
Etc etc...
A toi de voir!

En fait, je me base sur SQLite pour établir mon code (d'ou l'intéret de séparer la classe de base et les autres), et par rapport à ca, j'aurai une proposition :

abstract class DBMain
   + method() : connect
   + method() : open
   + method() : select_db
   + method() : close
   + method() : last_error
   + method() : version
   + method() : free_result

abstract class DBResults extends DBMain
   + method() : fetch
   + method() : query
   + method() : single_query
   + method() : fetch_all
   + method() : fetch_array
   + method() : fetch_object
    * avec une instance de DBIterators pour key, current, next, prev, ...

abstract class DBUnbeffered extends DBMain
   + method() : fetch
   + method() : query
   + method() : single_query
   + method() : fetch_all
   + method() : fetch_array
   + method() : fetch_object
   * chaques fonctions appelent ensuite la fonction free_result

Par contre j'ai un soucis pour mes classes mysql, mssql et autres, je devrait en faire deux, une pour DBResults et DBUnbeffered ou si je fait
class mysql extends DBMain, ca marcherait ?

Qu'en pense-tu ?