Salut
Le 26 mars 2013 09:37, Ousmane SAMBA <[email protected]> a écrit :
je pense que Alioune Dia devrait eviter certain propos sur cette liste si
c'est juste d'un ORM PHP dont on parle :
- va voir http://www.doctrine-project.org/ et http://propelorm.org/
Tu vera que tes requetes se feront de manières similaire aux examples que tu
a donné.
Je n'ai pas encore téléchargé le code de http://www.doctrine-project.org
mais si ca fait comme ORM django/SQLaLCHIMy alors disons
alors ORM kiff kiff (match null :-)
Mes remarques sur http://propelorm.org/ !
Je n'ai pas vu le code de http://propelorm.org/ , mais ce que j'ai vu
sur le site
de l'accueil ne me rassure pas !. Si l'ORM donne des choses du genre , il
ya un problème.
<?php
$book = BookQuery::create()->findPK(123); // retrieve a record from a database
$book->setName('Don\'t be Hax0red!'); // modify. Don't worry about escaping
$book->save(); // persist the modification to the database
$books = BookQuery::create() // retrieve all books...
->filterByPublishYear(2009) // ... published in 2009
->orderByTitle() // ... ordered by title
->joinWith('Book.Author') // ... with their author
->find();
?>
1—
Il y'a une redéfinition du Manager , retourné par la methode —
create()— , et il fait
un surcharge de cette classe pour chaque type d'object. il a
redéfinit Manager
en BookQuery::create() ==BookQueryManager , et il a redéfinît une méthode
comme — orderByTitle() — , alors que cette méthode est spécifique a un
— Book .Il va fausser ainsi l’abstraction , qui veut que Le Manager soit unique
pour n'importe quelle model. Je n'ai pas regarde le code , mais c'est comme si
il avait fait :
class Manager:
def __init__(self, model):
self.mode = self.model
def filter(self, name_to_filtre):
# Database Backend file
backend = MySql or PostGres or SqLite bAckend
return backend.filter( self.model, name)
Ensuite il a fait une truc qui ne sert a rien a savoir redéfinir le
Manager pour avoir
un BookQueryManager .
class BookQueryManager(Manager):
def __init__(self, model):
self.mode = self.model
def orderByTitle(self, name_to_filtre):
# Database Backend file
backend = MySql or PostGres or SqLite bAckend
return backend.orderByTitle( self.model)
Il faut certes des datas manager spécifiques , mais un Datas Manager
ne doit jamais contenir une méthode comme — orderByTitle.car cela va fausser
l'abstraction. ceci vaut également pour la method — filterByPublishYear .
Je préfère l'API de Bassirou Thiam a ORM http://propelorm.org/
Si c'est bien ce que je vois ?
2 —
Quand je lis
$books = BookQuery::create() // retrieve all books...
->filterByPublishYear(2009) // ... published in 2009
->orderByTitle() // ... ordered by title
->joinWith('Book.Author') // ... with their author
->find();
je suis un peux gêne par la syntaxe , L'ORM est sensé simplifié la vie
du développeur
mais pas complique, moi j'aurai préféré que :
Lors de la création du Manager — BookQuery::create() , qu'on spécifie
un flag —depth—
pour dire au manager s'il il doit faire la jointure — book.Athor — ,
ainsi joinWith sera
transparent et ne serait plus hard-coder comme ca .
Si je prends en compte mes deux remarques , j'aurai alors a la place de
$books = BookQuery::create() // retrieve all books...
->filterByPublishYear(2009) // ... published in 2009
->orderByTitle() // ... ordered by title
->joinWith('Book.Author') // ... with their author
->find();
$books = BookQuery::create(depth=True)
->filterBy(year =2009)
->find()
et pour chaque $book de $books , l'ORM va me linker 'Autor' si je precise
— depth =True
for each $book in $books :
$book.author
Donc si on devait parler de neurones je dirait que c'est toi qui n'en a pas
beaucoup parce qu'il est impossible pour toi d'exposer exactement ce que tu
veux.
Sans rancune !
aH bon , un ORM c'est pas un API ,
Espece d' ecervelet , tu est encore plus null que Bassirou Thiam , lui au moins
le code qu'il a fourni n'est pas très jolie , mais le niveau
d'abstraction ete elevé.
Bonne journée a tous !
Va te faire foutre :-)
—Ad