Reprise du message précédent :

Je note...par curiosité, pourquoi?

Hep les experts symfony 2, je suis en train de lire la partie "Model" du Book, et ils utilisent systématiquement des trucs de ce style dans les contrôleurs :

$product = $this->getDoctrine()>getRepository('AcmeStoreBundle:Product')

 
Ya que moi que ça choque un peu de retrouver des appels à l'ORM à cet endroit?

IT IS TOUT COTON DEHORS §§§§

c'est le top ²  
 
une cave a vin c'est un luxe, pour y mettre des produits de luxe a garder longtemps  
cx'esrt ptet un peu idiophile mais d'autres caves ont deja eu des pb (eclatement des bouchons/conservation) je prendrais pas le risque

$product = $this->getDoctrine()>getRepository('AcmeStoreBundle:Product')

tu préfererai rajouter encore une couche d'abstraction AbstractORM ?  
L'orm n'est pas quelque chose que tu changes en cours de projet.

Merci

$product = $this->getDoctrine()>getRepository('AcmeStoreBundle:Product')

 
Utilise Propel déjà pour commencer

C'est la OUATE !

Surement pas abstractORM, non.
Mais interagir avec des objets du modèle sans savoir ce qui se passe derrière me paraîtrait bien plus propre.
 
On est décidément bien loin du MVC...déjà en web la distinction entre la vue et le contrôleur est inexistante 99 fois sur 100, mais si tu couples en plus le contrôleur et le modèle jusqu'à l'ORM...

Si je vire Doctrine ce sera pour tout à faire à la bite et au couteau, en l'occurrence - vu le projet, la valeur ajoutée d'un ORM est plus que douteuse, ça représente plus une perte de temps qu'autre chose amha.

là, tu me parles de sucre syntaxique
dans tous les cas, une fois ton orm choisi,tu n'en changeras pas en cours de route , et il influencera très lourdement la façon d'utiliser ton modèle dans ton controleur
Donc au contraire, je trouve utile de voir dans le contrôleur que derrière c'est doctrine pour savoir quelle sont les méthodes à utiliser
Encore une fois, a moins que tu ne préfère ajouter une couche d'abstration foireuse qui sera le dénominateur commun entre propel/ doctrine 1/doctrine2/ .... et qui te barreras l'accès aux fonctionnalités avancées de chacun de ces ORM

wat  ?

D'ailleurs si quelqu'un peut m'expliquer quels sont les vrais avantages d'un ORM, ça m'intéresse grandement, parce-que si tu suis juste la doc symfony, avec un ORM il faut:
1) Te retaper la description complète de ta base de données avec une syntaxe à la con, alors qu'à-coté tu as des outils pour générer les scripts de création à-partir d'une représentation graphique.
1bis) Avoir un gros paquet de classes qui ne servent qu'à expliquer à l'ORM comment accéder à la base.
2) Soit apprendre la syntaxe de requêtage spécifique de ton ORM, soit te taper le sql à la main quand même.
 
Seriously, wtf?

 
OUATE ZE FUQUE §

générer automatiquement les formulaires CRUD
faire la gestion des versions de base de données ( et les migrations  auto entre ces versions)  
pouvoir passer d'une abse en mysql vers du pgsql ( apr exemple suite a un changement de licence d'oracle, ou suite a nu gel du dev sur mysql )  

http://www.lexpress.fr/actualite/p [...] 53746.html

 
Non, je te parle d'avoir une vraie séparation des couches.
Mettons que je suis un fou et que je veux changer la représentation de mes "product", je veux pas avoir à toucher à mon contrôleur parce-que le $this->getDoctrine()>getRepository('AcmeStoreBundle:Product') n'a plus aucun sens...
 

Renseigne-toi sur mvc.
En temps normal le point d'entrée de l'utilisateur c'est la vue, et ce n'est pas le contrôleur qui instancie la vue et lui passe les données.
Ok, en web tu retrouves régulièrement les termes "vue" et "controleur", qui font des choses différentes, mais le découpage n'est pas celui de mvc...

Je plussoie. On en a une depuis 5 ans, RAS. Super rapport qualité/prix, contrairement à Eurocave où tu tapes direct dans le haut de gamme. Discutes-en avec quelques pros (dans ton coin tu devrais en trouver ), mais je vois pas vraiment de raison de taper chez Eurocave plutôt que Climadiff pour un particulier amateur.

 
Je dois être crétin, je vois pas le rapport avec un ORM.
 

 
Mouais, ça ok.
 

Ca j'en fais autant avec pdo, à 3 requêtes vaguement spécifiques près. Pas de quoi fouetter un chat.

Je note donc, climadiff en pas trop cher et eurocave en haut de gamme.

Mais qui ici connaît Yannick Jadot ?
 
(skeye, tu as jeté un oeil à tout ce que fournit ActiveRecord dans ruby on rails?)

Pas moi.
 
(non, mais j'y jetterai un oeil à l'occasion...même si j'imagine que ça ne fait rien d'extraordinairement différent des ORM php...non? )

  http://www.polycave.fr/cave_beton.php

haut de gamme de locataire, si tu préfères.

Ca fait tout en fait. Tu crées ton schéma de base en DDL, et il va se débrouiller tout seul pour te créer (à l'éxécution, de façon dynamique) des classes qui matchent le schéma de base (via des INFOSCHEMA trucs), il va tout seul détecter quels sont les Ids de ta base.

Certains ORMS du même type (je sais pas si c'est le cas pour ActiveRecord) vont tous seuls te créer les tables à partir d'une classe, et y mettre les bons indexes si tu as les bonnes conventions de nommage.

Et tout seul, il va te fournir des fonctions de recherche. Ca te permet à partir d'un id refilé en POST de trouver le bon objet et d'avoir accès automatiquement à ses membres, et aux tables liées qui vont bien via les foreign keys avec très peu de code attaché.

edit: j'aime pas RoR, donc je te propose plutôt un tutorial sur SQLAlchemy, chez Python:
http://www.sqlalchemy.org/docs/orm [...] troduction

 
Ok, donc ça revient à peu près à ce que fait doctrine - tu décris ta base dans la syntaxe qui lui va bien, et derrière il te fournit le find/findall/create/update, grosso-merdo.
Et sait te générer les scripts de création/modification, si c'est pas déjà fait.
Pour une appli avec avec 5/6 tables et 3 écrans et demi je suis pas sûr d'y gagner vraiment, mais bon...on verra bien à l'usage.

L'un des gros avantage c'est le saccharose de la syntaxe, mais pour avoir utilisé des ORM sur des trucs pas bien complexes je me suis vite retrouvé à écrire du SQL custom

(Dans Django t'es baisé pour les migrations - l'ORM ne gère pas - si t'as pas l'outil qui va bien, par contre t'as la validation avant de taper la base, pre-save, post-save, et pleins de niceties. Mon expérience avec SQLAlchemy que cite Lamsette a été plus concluante, peut-être parce que c'est plus bas niveau?)

 
La validation est pas liée à l'ORM, normalement, non...?

Si je dis pas de conneries dans Django ça l'est

P'tin encore une canalisation de gaz pétée par un engin de BTP dans le coin
Un de ces 4 ils vont encore tout faire péter

http://www.lemonde.fr/economie/art [...] _3234.html
 
Faire moins bien que Christine Lagarde, c'est quand même fort. Doué le garçon.

Bizarre...si tu veux valider des données qui ne vont/viennent pas de la base t'as plus que la bite et le couteau?

Certes, mais Lagarde est exceptionnellement douée pour le pipotage. Pour ce qui est de la compétence, je ne sais pas comment elle arrive à faire illusion.

 
LOOK AT ME I SPEAK ENGLISH

Lagarde était pas première du même classement ? Je vois pas comment il pourrait faire mieux. Et du coup je me demande aussi si c'est vraiment une mauvaise chose d'être mal classé là où Lagarde était considérée comme la meilleure...

Voila, c'est à mon avis à ça que se résume la popularité de Lagourde et un handicap majeur de Baroin, qui ne parle même pas anglais correctement.
edit: elle a tout de même une compétence +10 en bronzage

Un classement d'économistes du FT, c'est probablement un point de vue ultra libéral (le redface est à peine utile ici ).

Pareil. De mon expérience, un ORM qui ne te permet pas de créer des requêtes custom avec des resultsets custom est à fuir pour raison de performances, car au final il est rare qu'on ait besoin de toutes les colonnes d'une table dans une requête. Dans SQLAlchemy, je n'utilise pratiquement jamais la partie ORM, uniquement la partie Core. La séparation Core/ORM est d'ailleurs la "key feature" numéro 1 de leur présentation. L'ORM est une facilité quand les perfs ne sont pas déterminantes, par exemple dans la présentation d'un formulaire. Mais pour tout le reste, j'évite.

Bah faut quand même valider que tu tentes pas de mettre la chaîne "3" dans un champ de type booléen.

Et tu peux faire des validations plus complexes si besoin, Django a un pipe de validation dans les modèles et un pipe de validation dans les forms, de même que tu valides les données quand elles arrivent de l'utilisateur et t'as des contraintes en db pour s'assurer que tu lui files pas des données bidon

T'as pas besoin d'écrire du SQL brut pour filtrer les colonnes récupérées : https://docs.djangoproject.com/en/d [...] ySet.defer

Pas uniquement. Enfin y a une validation niveau Model en effet (pour vérifier que tu fous pas une chaîne de caractères dans un champ int), mais après, dans le cas de skeye et d'une appli web, t'as aussi une validation coté formulaire, via les objets "Forms" de Django. Qui implémentent là aussi des règles assez basiques, mais qui sont facilement modifiables.
 
Edit : t1 burned by Masklinn

OK, c'est ce que j'appelle un resultset custom. Au lieu de spécifier les colonnes qu'on veut récupérer, on spécifie celles qu'on ne veut pas récupérer.

Avec Django tu as l'inverse de "defer", "only", qui te permet aussi de faire de cette façon (ie spécifier ce que tu veux récup)

 
1/ tu vas en général chercher à l'éviter le plus possible
2/ les couches bas niveau genre JDBC et autre le permettent déjà
3/ un ORM ne t'empeche pas de devoir faire du SQL custom pour des requetes touchy, et c'est précisément ces requêtes là qui sont merdiques à migrer parce que si un DBA est passé dessus, il aura optimisé au taquet pour ton RDBMS, et si tu changes faut tout refaire