Discussion :

[boutmos]

Bonjour,

Je fais appel a votre expérience pour vous poser une question concernant la facon (ou plutot l'endroit) ou se trouvent les requetes lorsqu'on developpe une application web avec le pattern MVC.

Je vous répondrais bien : "Les requêtes se trouvent dans le model" ...

Mais depuis que je pratique du MVC je vois tout et n'importe quoi que çà commence a me destabiliser.

La par exemple je reprends une application d'un de mes anciens collègue que j'estime calé en dev. Application réalisée avec le framework Kohanna.

Et que vois - je ?

Des requetes basées sur un ORM qui se trouvent dans ses controlleurs ...

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
	public function action_ajax_lister()
	{
        // recupere les informations utilisateur
		$u = Session::instance()->get('infos_gestionnaire');
 
		$utilisateur = ORM::factory('Utilisateurs')
			->where('uid', '=', $u['uid'])
			->find();
 
		// recupere les informations depot
		$id_depot  = $_GET['depot-id'];
 
		$depot = ORM::factory('Depots')
			->where('id_gestionnaire', '=', $utilisateur->id)
			->where('id', '=', $id_depot)
			->find();
 
		//var_dump($affectations->as_array());
		$utilisateurs = $depot->utilisateurs
			->order_by('nom', 'asc')
			->order_by('prenom', 'asc')
			->find_all()->as_array();
 
		// preparation du resultat JSON
		$o = new stdClass();
 
// etc 
// etc ...
    }

[papajoker]

Bonjour,

Oui c'est normal
on ne va pas écrire une méthode dans le model pour Model->findByID(4)
ou ce findAll() avec order

C'est donc tout a fait classique pour un petit-moyen site

Sinon il existe une méthode "lourde" :
les repository
les requetes sql ne sont pas dans les model ni dans les controleurs mais dans les repository
la, le controleur ne voit plus l'orm mais agit que sur le repository(pas le model), donc le code controleur est indépendant de l'orm

[Tsilefy]

Le rôle du contrôleur est de réagir à une requête get/post en appellant la logique métier qui correspondent à la requête et ensuite à appeler la vue qui doit afficher les résultats de cette logique. Converser avec la base de données est une responsabilité qui ne devrait pas lui appartenir (ORM ou pas ORM).

De plus, cela crée une dépendence significative entre controlleur et données.

Et si on a besoin de réutiliser la même logique (ou une logique proche) dans d'autres contrôleurs, le résultat sera une duplication inutile de code.

[boutmos]

Voilà, papajoker et Tsilefy ont des avis qui diffèrent

Cette notion de dépendance évoquée par Tsilefy me semble être un point fort.

[papajoker]

Voilà, papajoker et Tsilefy ont des avis qui diffèrent

Non je suis a 90% avec Tsilefy (voir plus)

tu n'as pas compris : soit une méthode controleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
fonction getUser(){
   $user = new ModelUser();
   $data= $user->find( $_GET['id']  );
   return View->render(  $data );
}

cette méthode utilise un ORM(ModelUser) et une requete de l'orm(find)
et ca ne me choque pas trop !

Bien sur il faut comprendre que ce code est exactement le même que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return View->render(  ORM::factory('user')->find($_GET['id']) );

c'est juste une petite différence d'écriture.

--------------
et je précise pour un appel simple (une seule méthode), pas d’enchaînements, ca ne me pose pas de probleme.

dans l'exemple il y avais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$depot = Depots::where('id_gestionnaire', '=', $utilisateur->id)
			->where('id', '=', $id_depot)
			->find();
$utilisateurs = $depot->utilisateurs
			->order_by('nom', 'asc')->order_by('prenom', 'asc')
			->find_all()->as_array();

ce qui me "choque" en premier lieu c'est l’enchaînement qui est clairement une dépendance métier, les requêtes, en deuxième.

----------------------
Je pense que la bonne réponse dépend du projet :
un projet a long terme (x personnes sur x années) ou une personne sur 15 jours sans maintenance.
D'un package(bundle) ou d'un code diffus dans un développement.

[ABCIWEB]

Je vous répondrais bien : "Les requêtes se trouvent dans le model" ...

Mais depuis que je pratique du MVC je vois tout et n'importe quoi que çà commence a me destabiliser.

Comme quoi il y a la théorie et la pratique...
MVC c'est un principe d'architecture mais suivant le cahier des charges de l'application chacun peut faire quelques exceptions dans cette organisation au cas par cas ou utiliser une variante généralisée à tout le développement.

On fait des exceptions bien souvent parce que c'est plus simple/optimisé par rapport au contexte. Bien entendu cela peut induire les inconvénients que Tsilefy a indiqué mais un développeur averti ne le fera qu'en connaissance de cause et en fonction des paramètres : temps de développement - optimisation code - évolution, qui sont eux-mêmes contradictoires.

Autrement dit et si comme tu le dis ce code provient d'un développeur chevronné, il a sans doute pensé que la dépendance induite dans le contrôleur n'était pas gênante pour cette application et/ou la fonction est peut-être difficile à reporter dans le modèle pour des problèmes d'organisation ou d'optimisation du code.

[boutmos]

Ok merci pour votre participation. C'est toujours interessant de voir des réponses claires qui sortent un peu de la définition pure du model MVC mais qui sont justifiées.

@papajoker : Je comprends mieux ton point de vue avec ta seconde explication

Si vous souhaitez continuer a alimenter ce fil et faire part de votre propre expérience en developement MVC, allez y de bon coeur

[Tsilefy]

Il faut respecter les bonnes pratiques, mais après, comme les autres l'ont dit, il y a une réalité dont il faut tenir compte.

La réalité, c'est:
- si je suis à 100% sûr que mon controlleur n'évoluera plus jamais, je peux rajouter une petite couche métier à l'intérieur.
- si le client me paie pour développer rapidement un truc qui marche, sans se soucier s'il est évolutif ou pas, s'il sera facile à maintenir ou pas, qui suis-je pour le lui refuser, à partir du moment où il est au courant de tous les faits?

Le tout c'est d'éviter le cercle infernal (et je parle d'expérience):
- tiens, j'ai besoin d'une petite fonctionnalité dans mon controleur, je vais l'ajouter ici, je ne vais pas modifier le modèle pour ça.
- Tiens, j'ai aussi besoin d'une autre fonctionnalité dans cet autre controleur. Tant qu'on y est, continuons à le modifier ici, après tout ce n'est qu'un petit accroc aux bonnes pratiques, l'essentiel c'est que ça marche.
- tiens, je me retrouve avec des méthodes qui font plusieurs dizaines de lignes et qui partagent plus ou moins le même code, avec des appels à l'ORM, du logging, des APIs. Il va falloir que refactorise tout ça.
- [un an passe... entre-temps, je suis passé à d'autres projets sur d'autres frameworks]
- tiens, la vielle application a besoin d'une nouvelle fonctionnalité. J'ouvre le projet dans Netbeans et je peste: qui a écrit ce code déguelasse et difficile à comprendre et à modifier?