par
naholyr » 23 avr. 2008, 22:58
Un des gros avantages de Propel c'est le système d'abstraction interne (nommé "Creole") : On crée un objet de la classe "Criteria", et on le remplit avec les critères qu'on veut appliquer à notre sélection.
Ça semble lourd, voire idiot, comme ça. Mais le gros intérêt c'est qu'on peut trimballer cet objet, le modifier, ajouter/modifier des critères à la volée, changer l'ordre de tri, etc...
Par exemple si on a deux applications on pourra très bien imaginer que côté frontend on ajoute un critère à toutes les requêtes de sélection sur telle table pour exclure les objets cachés.
Pas besoin de parser du SQL et de le modifier comme on peut à la volée, on appelle simplement $criteria->add(MaTablePeer::HIDDEN, false)
C'est un des avantages spécifiques à Propel. Après pour le "pourquoi un ORM", à la rigueur je pense que Wikipedia répondra mieux que moi.
Un des gros avantages de Propel c'est le système d'abstraction interne (nommé "Creole") : On crée un objet de la classe "Criteria", et on le remplit avec les critères qu'on veut appliquer à notre sélection.
Ça semble lourd, voire idiot, comme ça. Mais le gros intérêt c'est qu'on peut trimballer cet objet, le modifier, ajouter/modifier des critères à la volée, changer l'ordre de tri, etc...
Par exemple si on a deux applications on pourra très bien imaginer que côté frontend on ajoute un critère à toutes les requêtes de sélection sur telle table pour exclure les objets cachés.
Pas besoin de parser du SQL et de le modifier comme on peut à la volée, on appelle simplement $criteria->add(MaTablePeer::HIDDEN, false) :)
C'est un des avantages spécifiques à Propel. Après pour le "pourquoi un ORM", à la rigueur je pense que Wikipedia répondra mieux que moi.
