Où placer les requêtes SQL (sans utiliser d'ORM)

Version imprimable

04/12/2012, 09h57
xhion

Où placer les requêtes SQL (sans utiliser d'ORM)

Bonjour,

Je viens tout juste de finir de lire la documentation de symfony 2 et je souhaiterai avoir une petite précision.

Quelles est la bonne façon de faire si l'on utilise pas d'ORM,

Doit-on placer nos différentes requêtes (sql pdo par ex) dans une classe "Model" et renvoyer des tableaux de données (par ex)

ou

Doit-on placer nos requêtes dans une classe "Service" et instancier une classe model qui contiendrai simplement des "getteur" et des "setteur" ?

J'espère que j'ai été claire dans l'exposition de mon problème.

Merci d'avance
04/12/2012, 11h41
seb_perl

Pourquoi ne pas passer par un ORM ?
04/12/2012, 11h44
xhion

J'utiliserai un ORM mais c'est une question que je me posait ;)
05/12/2012, 16h21
ovh

Solution 2 :)

Citation:

Envoyé par xhion

Doit-on placer nos requêtes dans une classe "Service" et instancier une classe model qui contiendrai simplement des "getteur" et des "setteur" ?
12/12/2012, 16h01
Nico_F

Qu'est-ce qui t’empêche de les placer au même endroit que les autres : dans les repository ?
19/12/2012, 14h22
ovh

Citation:

Envoyé par Nico_F

Qu'est-ce qui t’empêche de les placer au même endroit que les autres : dans les repository ?

Il a dit qu'il n'utilisait pas l'ORM ;)

D'où l'emploi de classes "services" de manière générique, mais ça peut être concrètement des classes de "repositories" si on s'en réfère aux termes Doctrine.
20/12/2012, 09h51
Nico_F

Citation:

J'utiliserai un ORM mais c'est une question que je me posait

Ce que j'ai compris c'est qu'il allait utiliser un ORM mais qu'il voulait également exécuter des requêtes natives et qu'il ne savait pas ou les placer.

Par extension, je ne sais pas si ça concerne ton problème ou pas mais c'est toujours bon à prendre, il est possible de faire des requêtes natives et ensuite de les mapper à ton modèle sans être obligé de faire des classes model supplémentaires : via le ResultSetMappingBuilder de Doctrine.

Celà permet d'utiliser des fonctions propres au SGBD dans la requête (ce que doctrine ne peut pas faire), d'exécuter potentiellement des requêtes complexes qu'il aurait été difficile de transcrire via le query builder, et de garder la notion objet par la suite en manipulant un graphe d'objet.