Avoir une partir du forum consacrée a l'objet vas permettre d'éviter de mélanger les sujets sur procédurale et POO sur le forum PHP5.

Petite question pour le premier topic, je gère mes connections avec mysqli qui est un connecteur basique de PHP, jusque la je trouvais ca bien pratique mais j'aimerais m'orienter sur quelque chose de plus poussé permettant de faire de la réplication et abstraction de base de donnée, pour optimiser au maximum un extranet.

En fait j'ai entendu parler d'ORM, que c'est le système utiliser par des framework type Zend, donc ca doit être assez intéressant de me tourner vers ce genre de solutions. Maintenant il doit en exister un paquet et je sais pas si c'est la meilleur manière de faire.

Donc utiliser un ORM qui existe ? trouver quelque chose qui pourrait être adapté a mes besoins ? ou éviter d'utiliser sans un framework qui tourne derrière ?

Tu peux bien entendu utiliser ton propre ORM, un ORM "reconnu" ou un framework complet.

Ce qu'il faut savoir, c'est :
- utiliser le tiens, ça sera réinventer la roue, et donc forcément faire quelque chose de moins bien qu'un développement maintenu par des milliers de personnes

- utiliser un ORM reconnu, c'est perdre le temps a la comprendre et à l'utiliser correctement

- utiliser un framework, c'est souvent reprendre ton dev depuis le début pour faire rentrer le bouzin

Maintenant, je te conseille tout de même de te tourner vers des ORM reconnu tels que Propel ou Doctrine
Ces deux ORM vont au delà de la simple abstraction de données et te propose la génération d'objet pour manipuler tes données en base de données.

L'ennui c'est que ni Propel ni Doctrine ne prennent en charge implicitement ou explicitement le verrouillage d'objets, ce qui est plutôt pénalisant, voir rédhibitoire pour une couche logicielle qui a pour vocation de faire un clone mémoire des infos stockées...

[ed] Très bonne initiative, cette rubrique "développement objet" évitera beaucoup de baratins...


Tracker.

Cyrano, mcorgnet et HyWaN sont en train d'en faire un au passage...

Forcement que ce soit pour utiliser un ORM ou me mettre a un framework il vas me falloir du temps mais c'est aussi bien que je vois ce qu'est et ce que fais un ORM avant d'utiliser un framework, comme ca je pourrais savoir exactement ce que je fais.

Pour propel je vais regarder comment il marche par contre l'histoire des verrous j'ai pas vraiment compris de quoi vous parliez. Pour la transformation d'une table en objet la ca deviens assez intéressant.

Si je dois recoder un ORM c'est sur que c'est réinventer la roue mais pour l'instant j'ai fais de l'objet pour l'extranet et j'ai certainement perdu du temps et de la perfection mais je vois aussi très bien comment gérer mes classes, les liaisons les heritages etc que je n'aurais pas forcement saisi en foncant sur un framework.

Les ORM ont pour but (en autres) de transformer un enregistrement [en base] en objet [en mémoire], et c'est plutôt souple et pratique.
L'ennui c'est qu'avec les implémentations existantes, plusieurs threads [utilisateurs] peuvent monter en mémoire le même enregistrement, travailler avec [modification du contenu] et à la fin du compte le remettre en base sans être inquiété le moins du monde. Pour éviter ce type de dérive (super risqué niveau intégrité) il faut avoir recours au verrous sur enregistrements, encore faudrait-il que propel ou autre propose des api...


Tracker.

ta ta ta...
alors comme ça, emporté par l'enthousiasme, on oublie les bonnes manières ?

Modération :
agité, merci d'utiliser un titre clair et qui correspond bien à ta demande.

Tu peux corriger ton titre en éditant ton premier message.

Merci de prendre le temps de lire les règlements.

Ce qu'il faut savoir, c'est :
- utiliser le tiens, ça sera réinventer la roue, et donc forcément faire quelque chose de moins bien qu'un développement maintenu par des milliers de personnes

Le genre de réflexion qui fait que rien n'existerait en informatique si tout le monde pensait comme ça. Il fautr au contraire réinventer la roue encore et encore.

L'abstraction de donnée est assez simple à faire mais il est vrai que c'est redondant à recoder, pour avoir utilisé adodb un certains nombre de fois ces dernières années je te le recommanderais franchement, la syntazxe peut plaire ou pas mais adodb fait tout et le fait bien quan d il s'agit d'abstraction

Agité parlait d'ORM, pas d'une couche DAL.


Tracker

ta ta ta...
alors comme ça, emporté par l'enthousiasme, on oublie les bonnes manières ?

Modération :
agité, merci d'utiliser un titre clair et qui correspond bien à ta demande.

Tu peux corriger ton titre en éditant ton premier message.

Merci de prendre le temps de lire les règlements.

c'est corrigé

edit : @Tracker : c'est quoi une couche DAL ?

Ce qu'il faut savoir, c'est :
- utiliser le tiens, ça sera réinventer la roue, et donc forcément faire quelque chose de moins bien qu'un développement maintenu par des milliers de personnes

Le genre de réflexion qui fait que rien n'existerait en informatique si tout le monde pensait comme ça. Il fautr au contraire réinventer la roue encore et encore.

Pour moi, c'est un choix.
Si je veux développer en me concentrant sur la logique métier de mon appli, je ne réinvente pas la roue.
Si je veux réinventer la roue, je me met sur sa construction. Mais je ne mélange pas les deux

edit : @Tracker : c'est quoi une couche DAL ?

Une simple couche d'abstraction d'accès au BD (genre ODBC)

edit : @Tracker : c'est quoi une couche DAL ?

Une simple couche d'abstraction d'accès au BD (genre ODBC)

Ok donc ODBC comme PDO sont des couches d'abstractions.

mysqli et mysql sont juste des extensions spécialisées pour mysql mais qui sont aussi des couches d'abstractions.

DAL = Database Abstraction Layer = Ensemble d'API permettant l'accès à "tout type" de base (sous entendues compatible avec SQL99 par exemple).
Donc OBDC, OleDB, ADO, JDBC, PDO, Créole, etc... sont des DAL.

Par contre php_mysql, php_pgsql, etc... sont eux des API mono base, aucune notion d'abstraction (tu seras obligé de réécrire ton code pour une migration de mysql à pgsql).

Après entre les ORM purs type Propel, ezPDO, etc... et les DAL y'a quelques hybrides comme ActiveRecord, Zend_Db_Table_xxx, etc...


Tracker.

Hey ,

Attention, on mélange pas mal de chose ici . PDO pour PHP, ODBC pour Microsoft, sont des DAL, des couches d'abstraction pour une relation vers une base de données. Jusque là, on est d'accord.

Un ORM (Object Relational Mapping pour mémoire) est un modèle objet qui permet de travailler sur une base de données relationnelle. Donc à travers l'objet, on atteint la base de données.

Très souvent, les ORM intègrent une couche DAL (ou un DAL, je ne sais pas trop comment on dit ) pour se simplifier la vie. Si on fait les choses, autant les faire en entier .

Maintenant, faire une abstraction, soit un ORM, n'est pas si simple. C'est même très dur, très très dur. Coller le plus possible à l'objet, i.e. intégrer les notions d'héritage, d'association, donc d'agrégation, de composition, etc., afin de correspondre (map) avec un modèle relationnel est un exercice de haute voltige.
Premièrement, il faut un modèle qui soit irréprochable. C'est à dire qu'il doit être d'une simplicité remarquable et ultra modulaire afin de ne jamais rencontrer de soucis ou de cas imprévu. Comme SQL est un langage plutôt « complexe », dans le sens où on peut emboîter beaucoup de chose, on doit pouvoir en faire autant avec notre modèle. Le modèle doit également être simple à cause du constructeur syntaxique, mais ça, c'est secondaire.
Deuxièmement, l'utilisation. Si on utilise un ORM, c'est pour améliorer l'expérience utilisateur. Ça aurait même du être mon premier point en fait. Personne ne l'a évoqué ici et c'est bien dommage. Pourquoi fait-on un DAL ? Afin d'améliorer la maintenance et l'expérience utilisateur. Par expérience utilisateur, j'entends la manipulation de la base de données (ici connexion, soumission de requête, etc.). Donc pour l'ORM, c'est identique. On n'a pas envie d'écrire nos sélections, nos mises à jour, et tout le toutime systématiquement. C'est lassant, très lassant. Et très souvent, on remarque qu'une base de données correspond à un modèle objet (voir les méthodes MERISE). Exemple : une table Personne et une table Médecin. Un médecin est une personne, mais on aurait 2 tables distinctes, c'est bête, et lourd à gérer. Toujours 2 requêtes à écrire. Donc l'ORM se propose de faire ça pour nous. Il va savoir que Médecin hérite des propriétés de Personne, et il va lui-même effectuer notre travail quand on va appeler la méthode insert ou update par exemple.

Donc c'est ça un ORM. Peu importe la méthode, la technique et la philosophie (d'ailleurs, je ne suis pas toujours d'accord avec ce que dit Tracker sur sa vision de l'ORM). Il faut juste améliorer l'expérience utilisateur au mieux. Pour les cas simples et récurrents, il faut écrire un strict minimum de code. Pour des cas un peu plus complexes et tordus, on aura un peu plus de code, voire même du code verbeux, mais ce n'est pas grave, ce sont des cas rares.

L'image que Tracker a de l'ORM quand il parle de mise en mémoire par exemple, c'est un ORM type Java : EJB par exemple. Mais on ne peut pas faire ça en PHP, ce serait beaucoup trop lourd.
Sékil avait dit une chose pas bête du tout une fois (je ne retrouve plus le sujet), c'est que PHP rencontre du succès car il répond aux exigences du Web, à savoir : il fait les choses bien et vite. Une application écrite en Objective C ou Java est appelée à être exécutée 1 seule fois en même temps (sauf cas particulier). Une application écrite en PHP est appelée à être exécutée des 10 000 fois à la minute, voire 10 fois plus pour de grosses applications. On ne peut pas déployer un système comme les EJB en PHP, c'est du suicide et de la folie furieuse (et un non-sens effrayant …).

Propel n'est pas vraiment un ORM. Enfin, pas au sens où je vois l'ORM. Mais il s'en approche c'est sûr. ezPDO n'en est pas un du tout, c'est un PDO like en gros. Pour Zend, leur système a un défaut, il est très très lourd. Il s'effondre même (cf. § précédent).

Il est vrai qu'avec mcorgnet, je travaille sur un ORM. Même si Cyrano n'y travaille plus (faute de temps), la porte lui reste grande ouverte, et il le sait. Mais revenons-en au sujet : j'y travaille avec mcorgnet. C'est pour ça que j'ai pas mal réfléchit à la chose . Et pour les petits malins qui pensent que faire un ORM, c'est facile, voici une petite estimation : les réflexions sur le forum à propos de l'ORM ont commencé le 12 avril, nous sommes le 11 aout. J'ai écrit les premières (les 600 premières en fait) lignes de code il y a 5 jours. Ça fait donc 5 mois de réflexions plutôt intenses.
Donc pour une fois, je suis d'accord avec zeus quand il dit qu'il ne faut pas réinventer la roue. (Et d'ailleurs, son dernier message est plein de bon sens). S'attaquer à construire un ORM n'est pas une tâche simple, il faut réinventer une roue plus petite .

En conclusion agité : voit du côté de Propel et Doctrine, ce sera un bon début .