j'apprends php 2
Le
Olivier Masson
Bonjour,
Je continue mon apprentissage actif avec la lecture de "PHP5 avancé" qui
est un peu creux, comme de nombreux livres de ce type, mais bon, ça
parle un peu objet, c'est déjà ça.
Mes interrogations actuelles concernent les divers outils et concepts
populaires.
Tout d'abord, je n'ai pas compris l'utilité d'un ORM. J'ai regardé la
très concise présentation de Doctrine sur wikipedia, mais c'est un CRUD.
Donc, en gros, à quoi sert un ORM ?
Ensuite, la fameuse question des frameworks. J'utiliserais bien
volontiers un framework solide puisque je considère qu'un tel outil,
conçu et entretenu par des dev très compétents (en tout cas cent fois
plus que moi) et corrigé par beaucoup de monde pourrait être très utile
et productif.
Seulement, il y a deux points qui m'effraient :
- la lourdeur de certains (symphony)
- la vitesse de changement des versions avec pas mal d'incompatibilités
ascendantes (à peine peut-on finir un projet sous ZF 1.6 que la 1.8
sort, etc.)
Pour le premier point, à l'inverse, un CakePHP ne contient pas grand
chose (du moins pas suffisamment pour que je puisse y trouver un réel
intérêt, je crois). Mais un Symfony semble énorme et on n'est plus dans
l'utilisation de briques (ce que j'aurais voulu) mais directement dans
l'élaboration d'un immeuble même si l'on souhaite construire un muret.
Pour le second point, c'est surement un avantage, mais c'est assez
décourageant car si je pars dans l'apprentissage de ZF N ou Symfony M,
quel temps devrais-je encore consacrer pour me faire à la N+1 ou M+1 ?
Merci de votre attention :)
Je continue mon apprentissage actif avec la lecture de "PHP5 avancé" qui
est un peu creux, comme de nombreux livres de ce type, mais bon, ça
parle un peu objet, c'est déjà ça.
Mes interrogations actuelles concernent les divers outils et concepts
populaires.
Tout d'abord, je n'ai pas compris l'utilité d'un ORM. J'ai regardé la
très concise présentation de Doctrine sur wikipedia, mais c'est un CRUD.
Donc, en gros, à quoi sert un ORM ?
Ensuite, la fameuse question des frameworks. J'utiliserais bien
volontiers un framework solide puisque je considère qu'un tel outil,
conçu et entretenu par des dev très compétents (en tout cas cent fois
plus que moi) et corrigé par beaucoup de monde pourrait être très utile
et productif.
Seulement, il y a deux points qui m'effraient :
- la lourdeur de certains (symphony)
- la vitesse de changement des versions avec pas mal d'incompatibilités
ascendantes (à peine peut-on finir un projet sous ZF 1.6 que la 1.8
sort, etc.)
Pour le premier point, à l'inverse, un CakePHP ne contient pas grand
chose (du moins pas suffisamment pour que je puisse y trouver un réel
intérêt, je crois). Mais un Symfony semble énorme et on n'est plus dans
l'utilisation de briques (ce que j'aurais voulu) mais directement dans
l'élaboration d'un immeuble même si l'on souhaite construire un muret.
Pour le second point, c'est surement un avantage, mais c'est assez
décourageant car si je pars dans l'apprentissage de ZF N ou Symfony M,
quel temps devrais-je encore consacrer pour me faire à la N+1 ou M+1 ?
Merci de votre attention :)
Poser une question
Bonjour,
Pour moi, un ORM est une sorte de CRUD version POO.
Il permet à un même programme applicatif d'adresser des requêtes SQL à
une base de données relationnelle, indépendamment du SGBDR utilisé.
Ce système devient, évidemment, inutile (ou très allégé) si on s'adresse
à une base de données orientée objet.
Avec un peu de recul, je dirais qu'il y a un malentendu à propos des
frameworks (ou cadriciels, pour les académiciens scrupuleux).
Ceux-ci, quelque soit le langage, semblent plutôt destinés à construire
des applications lourdes, comme celles développées par des éditeurs,
open source ou pas (par exemple un CMS basé sur Zend Framework).
Dans ce contexte, il est nécessaire d'avoir une architecture modulaire
très poussée et une grande robustesse du code, ce qui justifie l'emploi
de tels outils et la tolérance en regard de leurs coûts d'appropriation
et d'exploitation (lourdeur, lenteur, apprentissage, personnalisation).
En dehors de ces cas, et spécifiquement pour PHP, je conseillerais deux
solutions :
1. Classiquement, pour des petits projets, peu évolutifs et non
modularisés, ne pas oublier que PHP est déjà en lui-même un système de
templates. Donc, juste séparer la partie "applicative" (PHP, objet ou
pas) de la présentation (HTML + quelques "echo", boucles et tests PHP).
2. Pour des projets moyens, mais évolutifs et modularisés, construire
son propre framework allégé. Un MVC en POO peut être une bonne idée dans
ce cas, sans rien exagérer dans son architecture (pas d'usine à gaz).
Cordialement,
Pascal
Abréviations utilisées (pour tous) :
- ORM, Object-Relational Mapping
- CRUD, Create/Retrieve/Update/Delete
- POO, Programmation Orientée Objet
- SGBDR, Système de Gestion de Base de Données Relationnelle
- CMS, Content Management System (ou Software)
- MVC, Model/Controller/View
Ok, donc c'est bien ça.
Je ne demanderai pas ce qu'est une base de données orientée objet, parce
que je vais finir par m'y perdre :)
Pourquoi dans ce cas ne pas utiliser des CMF (Content Management
Framework) comme Drupal et surtout modx ?
C'est ce que je fais en partie, mais comme je le disais, je souhaitais
me reposer sur un framework pour améliorer ma productivité et la qualité
du code (également la sécurité de l'appli).
Par exemple, là j'ai un module membre à faire. On en voit partout. La
base n'est vraiment pas compliqué à faire mais si on doit parfaitement
gérer les sessions, les autorisations et qu'en plus l'inscription doit
se faire avec réponse à un mail, c'est déjà plus compliqué.
Je l'ai déjà fait mais forcément pas très bien, vu mon niveau et dans
tous les cas beaucoup moins bien que si ça avait été fait par des
développeurs confirmés.
Idem pour le CRUD. Etc.
Quant au MVC, je n'en voyais jusqu'à présent pas trop l'intérêt pour moi
mais avec des sites multilangues et l'optimisation pour le
référencement, ce serait utile.
Merci pour ta réponse.
s/de nombreux/la grande majorité/
Je pense qu'il y a plus intéressant comme littérature sur l'OO...
Ca dépend du contexte...
L'idée de base est d'utiliser des classes métier persistantes au lieu de
"rows" bruts tels que retournés par la base de donnée, et donc de
pouvoir d'une part encapsuler toute les règles métier en un seul endroit
et d'autre part abstraire l'essentiel du SQL (en déléguant sa génération
à l'ORM).
L'intérêt effectif dépend du type d'application, du langage et de la
techno (server page ou long running process), de l'ORM lui-même... Dans
Django (ORM spécifique) ou Pylons (SQLAlchemy), ça fonctionne plutôt
bien. En PHP, ceux que j'ai vu passer personnellement étaient codés avec
les pieds et présentaient plus d'inconvénient que d'avantages - mais
honnêtement je n'en ai pas essayé tant que ça. A vrai dire, je ne pense
pas que la techno PHP (langage procédural avec un modèle objet rikiki,
modèle d'exécution server page avec reconstruction du "monde" entier à
chaque requête HTTP, etc) se prête vraiment à cette approche (mon humble
avis, hein...).
Hem... Y a a boire et à manger. Et certains trucs dont, quand tu regarde
le code, tu te dis que tu es probablement trop modeste, et qu'il y a
nettement plus incompétent que toi.
"lourdeur" dans quel sens ? Complexité, ou mauvaises performances ?
On a testé CakePHP sur un (petit) projet, on n'est pas près d'y revenir.
C'est effectivement le problème avec la plupart des frameworks - et la
contrepartie d'un ensemble (supposé) cohérent et bien intégré.
D'un autre côté, même si ça semble parfois overkill pour des projets
simples, un bon framework peut aussi aider à construire rapidement un
muret - avec la possibilité d'en faire un immeuble par la suite sans
devoir raser le muret d'abord !-)
Je termine actuellement une petite galerie virtuelle toute simple pour
un ami peintre, et l'écrire avec Django m'aura pris moins longtemps que
de le coder en PHP pur et dur ou d'adapter un CMS existant - avec au
final un truc sur mesure.
Ca dépend de la politique du projet - certains essayent d'être assez
conservateurs (et donc de rester aussi compatibles que possible d'une
version à une autre, et de bien documenter les rares incompatibilités),
d'autres s'en fiche royalement. Dans le premier cas, c'est comme avec
n'importe quel outil, une fois le "premier apprentissage" effectué,
suivre les évolutions est assez facile, à condition de "pratiquer"
l'outil de façon régulière et de suivre __effectivement__ les
évolutions. Dans le second cas, bin, le mieux est probablement d'éviter
l'outil !-)
Mais qui ne parlent pas de PHP (tu me diras, c'est normal, puisque
pnepulo - on va abréger à partie de maintenant pour dire "PHP n'est pas
un langage objet -)...
Pourquoi m'obstiner avec PHP ? D'autant que Python n'est pas bien
compliqué. Ruby je ne connais pas. Est-ce que PHP6 prend davantage un
chemin OO où poursuit-on le chemin hybride ?
Mais un langage purement objet est-il finalement plus adapté au web ?
En fait je me fous d'utiliser PHP, Python ou Ruby, coder en objet ou
procédurale. Je cherche la rapidité de développement et la facilité de
maintenance ; pour la performance, vu les machines actuelles, ça semble
finalement secondaire.
Django c'est un framework Python. C'est un peu le bordel quand même (pas
Django, mais ces interpénétrations).
Doctrine, il sent des pieds comme ORM ?
Dès que je vois une class avec plein de choses magnifiques (final,
abstract, extends, protected, des doubles underscore...), j'estime que
le mec à un skill level (je vais me faire censurer par Olivier ;)) de folie.
Je commence à relativiser en me disant que ce sont surtout des gamins
qui ont bien appris leur cours et font la même chose en PHP qu'on leur a
appris en C++. Ce qui est surement bien, en partie.
Je dis ça après ce que tu affirmes ainsi que d'autres, mais également en
regardant le code de Drupal (peut-être pas un ref pour toi mais moi oui)
qui n'utilise semble-t-il pas du tout la POO... sauf en JS (normal).
Comme PEAR : l'obligation de te trimballer la pelle mécanique pour
planter ton pied de tomate.
Utiliser Symfony pour un petit site, ça me semble être du même acabit
que tous ces créateurs de site qui utilisent Joomla pour le site d'un
artisan qui va faire 300 visites/mois : démesuré.
Bon, va falloir choisir consciencieusement...
Au final je me rends compte que je veux faire comme les autres. Ce qui
est loin d'être dans mes habitudes, mais comme je me dis qu'un jour ou
l'autre, je vais finir par être salarié (nooooooooon !), faut que je
m'adapte à la demande. Et en province, on a pas trop le choix.
D'un autre côté, comme je disais, je cherche également à développer plus
intelligemment (rapidement, correctement...)
Est-ce compatible ? Il faut que je trouve cette compatibilité.
D'autant que la définition n'est pas très dure à trouver.
Pas d'accord. Même pour des applis très simples, un bon framework permet
de se simplifier énormément la vie.
Tu parles des framework PHP, là ?-) Parce que Django, c'est pas
exactement "lent et lourd".
Parce que ces "CMF" imposent des règles et des fonctionnement bien plus
complexes et contraignants - et très souvent totalement inadaptées au
besoin - qu'un framework applicatif.
(snip)
L'intérêt du (soi-disant) "MVC" [1] est surtout de séparer autant que
possibles les responsabilités:
- gestion des données et règles métier ("modèle")
- présentation ("vue")
- gestion des interactions utilisateur ("contrôleur")
Cette séparation facilite grandement la maintenabilité et l'évolutivité,
en comparaison du code spaghetti qu'on trouve typiquement dans du PHP
"old-school".
Accessoirement, un framework objet complexe n'est en rien nécessaire à
la mise en oeuvre d'un tel modèle. Ca peut se faire très simplement en
restant dans le modèle server page / procédural d'origine de PHP - à
condition d'être un peu discipliné...
[1] utiliser le terme MVC pour décrire les frameworks web auquel ce
terme est accolé est un abus de langage pur et simple - le MVC n'a de
sens que dans un GUI "classique". Mais bon, passons...