Discussion :

[Invité2]

Bonjour à toutes et à tous,

Voilà, mon projet prend forme, tout les modèles sont presques finient et, je me commence à étudier les contrôleurs déjà fait par mon collègue, ainsi que ses modèles...
Hors, je m'aperçoit que nos deux manières de coder sont différentes, ce qui est normal, mais sans parler du nommage des variables/classes/méthodes, ses méthodes sont plus fournies en conditions que les miennes, je m'explique, moi je me borne à ne faire que majoritairement des requêtes dans mes méthodes, oui, on ne travaille que en objet..., alors que lui va tester les droits, l'existence des arguments, faire la gestion d'erreurs, du cache etc...

Faut-il déléguer la gestion des erreurs au modèle ou aux contrôleurs ? Quelle est la bonne méthode à appliquer ? Pourquoi ?

Exemple type (et caricatural) :

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
31
32
33
34
35
36
37
38
39
40
41
Mon collègue
function fonction_type($nom, $prénom) 
{ 
   if(!gestion_droits::autorise('inscription')) 
   { 
      base::erreur('necessite_droit'); 
      return false; 
   } 
   if(!isset($nom) || empty($nom)) 
   { 
      base::erreur('nom_manquant'); 
      return false; 
// ... 
//requete SQL d'ajout 
} 
 
// Contrôleur 
fonction_type($_POST['nom'], $_POST['pseudo']); 
Base::parse('tpl/ajout_reussit.tpl'); 
 
// Moi
PHP: 
function fonction_type($nom, $prénom) 
{ 
   //requete SQL d'ajout (avec des protection, etc.) 
} 
 
// Contrôleur 
   if(!gestion_droits::autorise('inscription')) 
   { 
      base::erreur('necessite_droit'); 
      return false; 
   } 
   if(!isset($_POST['nom']) || empty($_POST['nom'])) 
   { 
      base::erreur('nom_manquant'); 
      return false; 
// ... 
// Si tout est bon 
fonction_type($_POST['nom'], $_POST['pseudo']); 
Base::parse('tpl/ajout_reussit.tpl');

Par avance merci de votre aide...

[meliandah]

Si vous avez réelement besoin de ces vérifications il faut les faires dans la fonction ( en étant sûr que ce soit valide dans tous les cas ), car sa t'évite de réécrire les contrôleurs a chaque page :s , apres si les autorisations diffères ou que les contrôles doivent être flexible, on peut rajouter un parametre a la fonction au lieu de les écrire a chaque fois

[Invité2]

Bah, mon premier soucis est d'avoir des modèles suffisament flexible et extensible pour avoir à en faire un "minimum"...
Donc ça serait mieu de faire ces contrôle dans le contrôleur ? (vérification)

[kaymak]

Je rejoins meliandah,
Si tu es tout à fait certain que ces vérifications ont à être vérifier tout le temps, alors implémente le dans la fonction.
Dans le doute, fais le dans le contrôleur.

Le mieux, à mon avis, étant de séparer les deux traitements avec deux fonctions.
1 pour effectuer l'insert sans vérifs, l'autre pour faire les vérifs + l'insert.
Ca correspond à un découpage métier/données. C'est je pense, la solution la plus optimum. Tes règles (métiers) sont encapsulées dans une fonction.
Si besoin tu pourras toujours appeler les méthodes d'insert (données) sans vérif.
Ce qui est utile pour les imports massif par exemple.

a plus

[Invité2]

Euh, j'avou ne pas y avoir pensé, :/
Le problème, c'est que ça va doubler le nombre de fonctions et bien ralentir mes scripts (je fais tout en POO...), non ?

[kaymak]

ben, au contraire. Si tu utilises php5, et seulement php5, alors c'est même mieux. Car avec php5 est arrivé une nouvelle fonction sacrément indispensable
=== > spl_autoload_register

et j'ai bien dit indispensable.
Car cette fonction te permet de faire du lazy loading vis-à-vis de tes classes. Le lazy loading <chargement fainéant> (traduction toute relative*), consiste à ne charger que ce que tu as besoin au moment ou tu en as besoin.

En clair, à chaque appel de classe, php vérifie si la classe existe dans son contexte d'exécution, si elle n'est pas déclarée, alors il parcourt les callback attaché via spl_autoload_register, jusqu'à ce que l'un d'entre eux déclare la dite classe dans le contexte, ou alors si aucun d'eux ne le trouvent, php jette une erreur fatal <Undefined class blahblah>.

Pour infos, sur un site en poo sans autoload, mes scripts faisait 10 mo en mémoire lors de l'execution, à cause de la déclaration des classes.
Avec autoload je suis passé à 1.5 mo.
Ce qui est bien plus adapté.

Je te laisses un exemple plus bas.

Si tu es en php4, pas d'autoload disponible, pour ce que j'en sais. Donc tu devras tout charger :\
Cependant, ne déperris pas sur place trop vite. Car avec tes modules de mises en cache d'opcodes tu dois pouvoir optimiser tout cela, je pense ici à APC, mem_chache(?), e_accelerator, ect...
Cependant il te faudra avoir la main sur la configuration du serveur pour faire cela.

Si tu n'es pas en php5, et que tu n'as pas accès à la conf serveur, alors oui, cela pesera plus lourd.
Cela s'en ressentira t'il ? Je ne sais pas.. Cela dépendra du nbre de fctions, du nbre de fichier, du serveur, de la charge, des caches existants ect.
Bref d'un tas de variables.

Le petit exemple :

Code loader.php :

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
31
32
33
34
35
 
<?php
function librairires_autoload($class_name){
	//class directories
	static $directorys = null;
	$dir = __CLASS_DIR__."librairies/";
 
	if( $directorys == null ){
		$directorys = array(
			$dir.'dataprovider/',
			$dir.'evenement/',
			$dir.'log/'
		);
 
		foreach( $directorys as $directory ){
			if( file_exists( $directory.'loader.php' ) ){
				include_once($directory.'loader.php');
			}
		}
	}
 
	if(file_exists($dir.$class_name . '.php')){
		require_once($dir.$class_name . '.php');
		return;
	}
 
	foreach( $directorys as $directory ){
		if(file_exists($directory.$class_name . '.php')){
			require_once($directory.$class_name . '.php');
			return;
		}
	}
}
spl_autoload_register('librairires_autoload');
?>

Le corps de la méthode est à adaptée à ta structure. Vu que le code est relativement court et simple je te laisse le décortiqué seul.

voila,
a plus