Forum du club des d�veloppeurs et IT Pro - Blogs - Architectures web hautes performances en bases de donn�es �paisses par tse_jc

[PHP] Comment g�rer correctement les sessions applicatives en PHP et le probl�me des cookies

tse_jc — Tue, 14 Jul 2020 15:13:26 GMT

1. Le probl�me des cookies dans la gestion des sessions applicatives PHP

Pour aller droit au but, placer les cookies au centre de votre strat�gie de gestion des sessions PHP pour vos applications web est une tr�s mauvaise id�e et reste � proscrire. En voici les principales raisons.
- Un cookie est stock� au niveau client applicatif et donc � l'ext�rieur de l'environnement de gestion d'une application web qui se situe c�t� serveur.
- �tant dans un environnement n tiers, chaque tiers ne peut faire confiance � ce qu'il re�oit de l'autre. C'est la r�gle fondamentale � appliquer au niveau s�curitaire.
En cons�quence, ce qui est plac� du c�t� navigateur client rel�ve du domaine "public" pour votre application, ce qui ne peut �tre d�cemment consid�r� comme source de confiance pour authentifier un utilisateur au sein de votre applicatif.

Rappel : Un serveur PHP utilise d�j� un cookie en gestion interne pour authentifier un utilisateur sur le serveur web. C'est une obligation technique, il reste incontournable et reste transparent pour tout le monde. Il ne sert � rien � rajouter un cookie applicatif qui reste une aberration � la vue de ce qui pr�c�de.

Utilisez des cookies sur vos sites, � des fins marketing et de prospection, en respectant la r�glementation, est une fa�on justifi�e d'utiliser des cookies, et je vous recommande vivement de vous en tenir � cette utilisation professionnellement parlant.

2. Les besoins techniques
a. Une session PHP ne doit pas �tre trop longue
Plusieurs raisons � cela. Comme il est expliqu� dans la documentation PHP, le module de sessions PHP n'est pas prot�g� naturellement contre les attaques au niveau des sessions, notamment via javascript. Plus une session est longue, plus elle a de chances d'�tre intercept�e et utilis�e pour acc�der � des informations normalement prot�g�es.

Principe n�1
La premi�re chose donc pour limiter la surface d'attaque de nos applications en PHP, consistera � faire en sorte d'avoir des sessions relativement restreintes dans la dur�e.

Seulement dans une application web d'entreprise, les utilisateurs d�testent devoir se reconnecter 50 fois dans la m�me journ�e, surtout si le mot de passe est compliqu�. Id�alement, il faut �viter de le faire plus de 2 fois par jour. Le plus g�n�ralement constat�, apr�s discussion avec des responsables en entreprise sur les enjeux au niveau s�curit�, il est g�n�ralement souhait� une p�riode de session sans interruption comprise entre 3 et 4h.

Une des premi�res solutions se pr�sentant � nous pour r�soudre ce probl�me et atteindre ce minima de 3 � 4 heures est de jouer sur la configuration de PHP au niveau du serveur afin de repousser le timeout de connexion PHP et la p�riode du Garbage collector � cette limite. Le seul avantage est la simplicit� de gestion ici, mais voil� : les d�savantages sont tr�s nombreux. Parmi les principaux, citons :

La r�duction de la capacit� de monter en charge du serveur HTTP, et la r�duction drastique du nombre de connexions concurrentes pouvant �tre g�r�es par le serveur. En effet l�optimisation d�un serveur web passe avant tout par la r�duction optimale du temps de r�ponse d�un serveur � une requ�te HTTP/HTTPS afin d�en lib�rer les ressources au plus t�t et permettre � une autre requ�te de se pr�senter.
On ne respecte pas le principe n�1 pour r�duire la surface d�attaque de notre application.

Principe n�2
Les vieilles sessions doivent �tre maintenues jusqu'� leur prise en charge par le gc (garbage collector)
Ne pas faire ainsi s'est s'exposer � des comportements instables voire erratiques dans un contexte concurrentiel.

Principe n�3
session_regenerate_id(true) et session_destroy() ne doivent jamais �tre utilis�es ensemble pour une session active.
Ce principe est directement issu du principe pr�c�dent.

b. G�rer les sessions via un double axe au minimum : PHP + Base de donn�es et id�alement sur un axe triple : PHP + DB + Cache Redis
Une fois �limin� la solution pr�c�dente qui fait le travail certes, mais qui n'est pas satisfaisante techniquement (dans un contexte d'optimisation d'infrastructure) et surtout au niveau s�curit�, il s'impose de suite la gestion selon un axe double.

Axe double : PHP + DB
Si on souhaite garder des sessions PHP � dur�e standard dans une configuration standard par d�faut pour le moins d�un c�t� et satisfaire � notre client�le, en leur permettant de ne pas se reconnecter avant 3 � 4 heures de travail, tout en ne travaillant pas sur leur poste de travail en mode continu, mais permettre un travail effectu� par intermittence et donc avec des p�riodes d�inactivit� incluses dans ce laps de temps imparti, on n�a pas le choix :

=> On g�re la dur�e de connexion applicative en base de donn�es et on g�re les sessions techniques pour traiter les requ�tes clients sur le serveur applicatif du c�t� PHP.

On peut donc d�duire d'un tel sc�nario les �v�nements suivants :

Une session applicative aura plusieurs id de session PHP diff�rentes au cours de sa vie.
Le gc va intervenir plusieurs fois au cours de la vie de notre session applicative.
A chaque intervention du gc on va devoir maintenir le contenu de la session PHP
le gc va intervenir sur des sessions pass�es et obsol�tes ( pas de probl�me de transmission de session), et peut intervenir aussi sur la session en cours en cas de p�riode d'inactivit� trop longue de l'utilisateur (probl�me de transmission de session).

Gestion du probl�me de transmission du contenu de session
En cas de p�riode d'inactivit� trop longue de l'utilisateur, il y a un risque de perte de contenu de session, et ce, d'autant plus que la p�riode du gc fix� est faible. Il faut donc stocker le contenu s�rialis� des informations de session ailleurs que dans le syst�me de gestion de sessions de PHP et ailleurs que dans un cookie bien �videmment. Une des meilleures pratique qui est recommand�e dans la documentation de PHP est de l'�crire dans un fichier sur disque hors dossier de sessions donc.

=> L'endroit ou l'on va sauvegarder ces informations de session constitue donc le 3e axe de gestion.

Si l'on reste ici sur un paradigme PHP+DB, on devra stocker l'information en DB.

Rappel de ce qui est stock� au niveau session

Il n'y a pas de variable globale stock�e directement en session pour pr�server les principes de la POO.
On recommande donc d'y stocker des objets s�rialis�s. En g�n�ral, comme on l'a vu dans un pr�c�dent billet, il y a en a au moins 3 : une classe utilisateur, une classe connexion et une classe module applicatif.

Les donn�es de type utilisateur et connexion sont limit�es et peuvent �tre restitu�es par la base de donn�es. Il s'agit tout au plus d'une dizaine de variables selon l'applicatif concern�.
Les donn�es de type module applicatif, quant � elles, sont sp�cifiques � la navigation de l'utilisateur et de ce qu'il a fait au cours de sa session de travail. Il y aura donc dans ce type de donn�es des donn�es calcul�es sp�cifiques mises en cache. Elles sont de nature non pr�dictive et il peut �tre tr�s co�teux de les recharger � partir de la base de donn�es. Pour le moins, l'exp�rience utilisateur s'en ferait sentir dans un contexte de charge au niveau des performances applicatives, si l'on d�cidait de ne pas maintenir ces donn�es dans ce contexte de transmission de session.

On pourrait bien �videmment scinder la gestion des deux premiers types de donn�es avec le troisi�me. Dans un tel sc�nario qui obligerait � stocker en variable globale cette fois un tableau s�rialis� des modules consult�s par l'utilisateur et � g�rer sp�cifiquement leur contenu � part hors db pour �viter de la solliciter et garder une capacit� de mont�e en charge applicative optimis�e, il y aurait un surco�t de gestion applicatif au prix de quelques efforts, mais cela resterait � prototyper au niveau performances pour se faire une bonne id�e de la chose. Toujours dans un tel sc�nario, le rechargement des deux premiers types de donn�es � partir de la base, bien que tr�s limit� et localis�, provoquerait une augmentation de charge pr�judiciable � l'applicatif.

Pr�f�rer/Privil�gier une gestion � trois axes
Du plus performant au moins performant, voici les choix � privil�gier dans un tel contexte de gestion de session.

Sauvegarde de l'int�gralit� du cache de session (3 types de donn�es) dans REDIS

Le cache �tant tr�s rapide et g�r� en m�moire, il n'y aura pas plus performant. Attention cependant, g�rer les sessions PHP directement dans REDIS n'a rien � voir avec ce qui est expos� ici, puisque le cache de session PHP dans REDIS serait soumis aux m�mes r�gles du gc que s'il �tait g�r� de fa�on traditionnelle. Cette solution � l'avantage en plus, d'�tre transparent techniquement dans le cloud.

Sauvegarde de l'int�gralit� du cache de session (3 types de donn�es) sur disque

Solution � privil�gier par d�faut donc surtout lorsqu'on est pas encore � l'aise avec la gestion d'un cache sp�cifique comme REDIS.

Note
Que cela soit avec REDIS ou directement sur Disque, rien n'emp�che d'utiliser un plugin PHP de binarisation de donn�es s�rialis�es (plugin compil� sur serveur) qui apporte un gain de performances notable dans un contexte de forte charge applicative et qui a fait ses preuves, m�me si cela ajoute un traitement suppl�mentaire des donn�es concern�es. Un tel syst�me est impl�mentable sur Microsoft Azure.

2. Algorithme d'impl�mentation
Je recommande de diviser votre algorithme en deux parties distinctes. La premi�re concerne la connexion initiale de l'utilisateur, lorsqu'il se connecte � l'application. La seconde concerne le ping de connexion au moment o� une requ�te utilisateur est envoy�e au serveur (rafraichissement du navigateur, requ�te ajax, ...). On pr�f�rera travailler ainsi en mode passif (pull) sur action de l'utilisateur pour optimiser la capacit� de mont�e en charge du serveur (on lib�re les ressources au plus t�t) plut�t qu'en push, qui consomme des ressources en permanence et limite potentiellement le nombre d'acc�s concurrentiels � l'applicatif beaucoup plus vite.

Il est probable voire fortement probable (je ne l'esp�re pas) que vous soyez oblig� de mettre en place des variables de gestion qui n'existaient pas jusqu'� maintenant dans votre environnement de gestion de sessions applicatif.
Voici celles que j'impl�mente dans mes solutions et qui me paraissent incontournables et minimales.

datetime de connexion
datetime derni�re requ�te serveur
session_id() PHP
Informations navigateur utilisateur ayant initi� la connexion
Adresse IP utilisateur connect� ayant initi� la connexion
Id technique de l'utilisateur connect�
Les donn�es s�rialis�es � maintenir
La dur�e maximale de session applicative
La dur�e de vie configur�e de votre gc

Remarques / Conseils
Essayez de ne conserver et de g�rer au niveau des variables de gestion que le strict n�cessaire pour offrir un service de qualit� et s�curis�, tout en ayant la possibilit� d'auditer sereinement vos sessions en cas d'anomalie constat�e. Trop de volum�trie au niveau de la base a aussi ses cons�quences et ne reste pas anodine.

� vous d'impl�menter vos algorithmes :)

SQL SERVER 2012+ : R�cup�ration param�tre OUTPUT d'une proc�dure stock�e avec PDO en PHP

tse_jc — Sat, 08 Jul 2017 14:32:31 GMT

Bonjour � tous,
La question est pourtant simple, mais j�ai pu constater qu�aucune r�ponse n��tait disponible sur aucun forum � cette question � part dans un contexte de requ�te pr�par�e.
Il est triste de constater de l�utilisation g�n�ralis�e des requ�tes pr�par�es en programmation web, et ce, pour plusieurs raisons.

L�argument universel des Injections SQL
Ceci est un tr�s mauvais argument, car comme je l�ai d�j� expliqu� ici sur d�veloppez.net Lorsque l�on effectue un contr�le syst�matique de type de contenu et de d�finition de chaque variable publique de son application, l�injection n�y est plus possible. (�) Donc � partir du moment o� on v�rifie soit m�me, pas besoin de PDO pour le faire quand surtout il n�est pas capable de contr�ler la pertinence des donn�es re�ues vis-�-vis du mod�le.

Il faut rappeler �galement que la mise en place d�une requ�te pr�par�e est co�teuse en terme de ressources et le faire de plus au niveau d�un driver externe au SGBDR est moins pertinent que de le faire au sein du SGBDR lui-m�me (qui est le plus apte � en g�rer les ressources associ�es) dans une proc�dure stock�e par exemple.
De plus, � moins de devoir ex�cuter cette requ�te un grand nombre de fois avec des param�tres diff�rents, il n�y a aucun int�r�t technique � privil�gier cette approche.

Un argument suppl�mentaire � cela: j'ai �t� surpris et d��u de constater sur les drivers PDO PHP 7 natifs pour SQL Server 2014 et 2016 qu'une requ�te appelant une proc�dure stock�e sans utiliser de requ�te pr�par�e au niveau PHP, avait recours � une requ�te pr�par�e au niveau du driver. Ce constat � �t� fait au niveau du SQL Profiler dans SSMS.

Ceci �tant dit, voyons comment r�cup�rer notre variable de type OUTPUT de notre proc�dure stock�e dans PDO d�une mani�re � normale � ou � classique � si vous pr�f�rez.
Voici la proc�dure stock�e qui va nous servir d�exemple

Code T-SQL : 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
USE MY_DATABASE; SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO IF OBJECT_ID('MON_SCHEMA.P_PROCEDURE_EXEMPLE') IS NOT NULL DROP PROCEDURE MON_SCHEMA.P_PROCEDURE_EXEMPLE; GO CREATE PROCEDURE MON_SCHEMA.P_PROCEDURE_EXEMPLE @user_id int = 0, @last_infos [varchar](50)='' OUTPUT AS BEGIN SET NOCOUNT ON; SELECT @last_infos=ma_colonne FROM MON_SCHEMA.MA_TABLE WHERE user_id=@user_id; IF @last_infos IS NULL RETURN 0; RETURN 1; END GO

Vous l�aurez compris ici, le but �tant de r�cup�rer la valeur de la variable @last_infos dans PDO. Pour rappel, on ne peut ici la placer au niveau du RETURN car seul un entier peut �tre retourn� par une proc�dure stock�e sous SQL SERVER.
Voici un exemple de comment proc�der pour r�cup�rer l�information qui nous int�resse.

Code PHP : S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
function get_informations($user_id){ $PDOInstance=new PDO(DSN_infos, USER_login, PWD_user); $PDOInstance->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION); // facultatif selon vos préférences
Code PHP : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$user_id=intval($user_id);
$query="DECLARE @last_infos varchar(250)
             EXEC MON_SCHEMA.P_PROCEDURE_EXEMPLE $user_id,@last_infos=@last_infos OUTPUT
             SELECT @last_infos";
try{
   $db_result = $PDOInstance->query($query)->fetchAll(PDO::FETCH_NUM);
} catch (Exception $e){
   if (strpos($e->getMessage(),'SQLSTATE[IMSSP]')!==false){return $db_result;}
  print ' @Err:[GET_informations] '.$e->getmessage();exit;
}
return $db_result;
}
Voil�. Vous voyez, il n�y a rien de difficile.
Bonne journ�e � vous.

AJAX : Comment structurer son code et cr�er un contr�leur sp�cifique en PHP

tse_jc — Mon, 29 Jun 2015 12:42:56 GMT

Bonjour � tous,

Sujet un peu vaste que j'aborde ici, mais qui me semble fondamental tant pour assurer une bonne structure applicative web que pour sa maintenabilit� dans le temps. J'ai vu en effet trop de code de sites ou d'applications web, dans lesquels la bonne organisation et structuration de leur code dans un contexte de gestion d'appels Ajax, �tait vraiment absente. Ce que je trouve assez regrettable.
Aujourd'hui, l'Ajax est une technologie incontournable dans les applications web pour plusieurs raisons dont voici � mon sens les principales :

la qualit� de l'exp�rience utilisateur ;
une meilleure segmentation et r�partition de charge applicative sur le r�seau ;
la gestion des caches client et serveur optimis�e, plus fine et plus efficace.

Avant d'entrer dans le vif du sujet, je tiens � pr�ciser que je ne vais pas parler dans ce billet du c�t� client et donc de la partie JavaScript de la gestion Ajax. Ce n'est pas l'objet de ce billet d'une part, et, d'autre part, j'estime qu'une telle structuration de code et d'optimisation est �troitement d�pendante de l'architecture et des technologies sp�cifiques choisies et utilis�es pour une application web c�t� client. Je dirai �galement pour finir, que malgr� cette diversit� de choix possibles c�t� client, tant au niveau architecture logicielle que de la structure et gestion des divers processus � ce niveau, il reste possible de d�finir des "constantes" de gestion qui peuvent se standardiser quel que soit le contexte. J'aurais l'occasion d'y revenir plus en d�tail dans un autre billet.

1) Pourquoi est-il important de structurer son code c�t� serveur dans un contexte Ajax ?
Sans vouloir jouer les rabats-joie, et revenir sur les fondements de la programmation orient�e objet ou sur l'int�r�t du patron MVC dans la programmation pour justifier de cette importance, voici � mon avis le pourquoi de ne pas n�gliger cette structuration dans une application web.

Dans une application web il est commun de consid�rer deux types de contr�leurs : le Front Controller, qui g�re les requ�tes utilisateurs pass�es au niveau de l'URL et le contr�leur applicatif qui g�re de fa�on g�n�rale les interactions entre la vue et le mod�le.
Dans les anciennes applications web et encore parmi certaines d'aujourd'hui qui ne sont pas con�ues autour d'Ajax, toutes les requ�tes utilisateurs passent par l'url et donc par un Front Controller qui centralise tout. Dans un contexte Ajax, ce Front Controller n'est plus seul dans la gestion de ces requ�tes utilisateur. Il les partage avec ce que j'appelle tout simplement un Controleur Ajax, qui consistue de fait et de fa�on g�n�rale un Front Controller asynchrone.
En r�sum� donc, dans une application web Ajax, on peut affirmer que l'on a non plus un Front Controller unique et global mais deux Front Controller : Un Front Controller synchrone et un Front Controller Asynchrone, qui se partagent � eux deux l'ensemble des requ�tes utilisateur sur le serveur.
En tant que controleur, le code s'y trouvant, se doit donc d'�tre structur� de fa�on logique et claire, je pense que tout le monde en conviendra.

2) Comment cr�er un contr�leur Ajax sp�cifique en PHP ?
Tout d'abord, je rappelle de la n�cessit� de bien s�parer le controleur applicatif du Front Controller dans un contexte MVC. Le client / la vue ne doit pas acc�der au contr�leur applicatif directement ne serait-ce que par s�curit�. On valide la requ�te et ses param�tres en type et en nature. Et lorsque les donn�es re�ues sont conformes, on les transmet au contr�leur applicatif en charge de la requ�te � traiter. Il est important dans une architecture n-tiers, que chaque tiers applicatif ne fasse pas confiance au premier abord � ce qu'il re�oit de l'autre. C'est d'ailleurs la responsabilit� primaire du serveur objet dans une architecture web en bases de donn�es �paisses, que de valider et de mettre en forme les requ�tes et donn�es du client aupr�s du SGBDR qui va les traiter.
Il est important �galement de ne pas faire du contr�leur Ajax et du contr�leur applicatif correspondant, un seul et unique controleur, m�me si la tentation peut �tre grande pour certains. En effet un controleur applicatif sp�cifique � la responsabilit� de gestion du cache des donn�es associ�es � cette sp�cificit�, responsabilit� qu'un Front Controller n'a pas et ne doit pas avoir.

Voici donc la solution que je vous propose et que je vous recommande pour structurer un tel contr�leur au sein de votre application. M�me si apr�s lecture la solution para�tra �vidente � certains, elle ne l'est pas toujours.

Beaucoup de choses � dire sur ce code :

c'est une classe statique qui a l'avantage d'�tre l�g�re, minimale niveau m�moire (pas d'instanciation, d'abstraction ni autre) et se pr�te bien au contexte d'ex�cution Ajax, on imprime le r�sultat de la requ�te pour l'envoyer au client ;
la gestion d'erreur est sp�cifique: on imprime directement l'erreur et on fait un exit(). => Le retour d'erreur est standardis� pour le navigateur et laiss� � JavaScript pour le rendre � l'utilisateur. Cela n'emp�che aucunement de loguer au niveau du SGBDR si cela est souhait� ;
on bloque automatiquement les requ�tes non g�r�es gr�ce au switch. Et plut�t que de retourner un message "requ�te non g�r�e" vous pouvez si vous le souhaitez, g�n�rer une erreur 404 ;
on oblige � standardiser les requ�tes Ajax. Il faut ici que le param�tre action soit toujours pr�sent, c'est-�-dire, dans toutes les requ�tes pour que la requ�te soit examin�e. On lib�re ainsi au plus t�t le serveur d'une requ�te non d�sir�e, et rien n'emp�che encore une fois de loguer les tentatives avant de renvoyer une erreur. (Attention au log ici pour ne pas vous faire saturer votre SGBDR ou votre disque dur par des logs intempestifs).
la classe joue son r�le de Front Controller. Elle filtre les requ�tes acceptables avant de les transmettre / faire suivre au contr�leur applicatif dont elle d�pend.

Voil� j'esp�re que ce petit tutoriel vous sera utile et vous aidera � faire progresser vos applications vers un code plus standard, optimis� et plus s�r.

A bient�t.

Le Singleton et le Dependency Injection pattern en PHP

tse_jc — Thu, 25 Jun 2015 00:02:40 GMT

Bonjour,

Voici un vaste sujet auquel je m'attaque ici, sujet qui fait d�bat surtout sur les blogs anglophones, parfois houleux, j'ai m�me lu un d�veloppeur qui disait "je ne parle plus aux d�veloppeurs qui n'utilisent pas d'injecteur de d�pendance dans leur d�veloppements, pour moi c'est une n�cessit� professionnelle de progression." (cf: Expos� en anglais sur l'injecteur de d�pendance et le singleton, source de cette d�claration)

Avant de commenter un tel propos et de recadrer et pond�rer les choses de la mani�re la plus objective que possible et sans parti pris, voici ce que la communaut� professionnelle a � reprocher au design pattern singleton de mani�re g�n�rale et r�currente:
- Il a un scope global un peu comme une variable globale;
- Il rends les tests unitaires difficiles voire impossibles.
- Il oblige � utiliser un couplage fort avec ses d�pendances, les cache m�me fortement, limitant l'�volutivit� et l'extensibilit� de ces d�pendances, rendant une telle t�che ardue et difficilement maintenable.
- Certains pensent m�me qu'il n'y a aucune utilit� � n'avoir qu'une seule instance d'une classe possible dans une application PHP.

Donc juste avant de r�pondre et d'argumenter, je pense qu'il est important de pr�ciser qu'il n'y a pas de bon ou de mauvais pattern de d�veloppement. Ils ont en effet tous leur utilit� et leur sp�cificit� ainsi que leur avantages et leur inconv�nients (il n'existe pas de solution universelle parfaite).
Comment faire ses choix dans un tel contexte? La r�ponse doit d'abord �tre issue de la ma�trise d'ouvrage, qui elle seule est en mesure d'�tablir l'architecture applicative adapt�e au cahier des charges lui m�me d�fini en fonction des pr�requis m�tiers et des contextes d'exploitation. Il se doit d'�tre objectif et neutre (sans parti pris) pour rester efficace et pertinent.

A partir de ces bases, il nous para�t d�j� �vident que les objections cit�es en d�but de billet, restent subjectives car hors d'un tel contexte. Mais ne nous contentons pas d'une telle observation et allons un peu plus loin dans l'�tude des besoins d'une application web.

Tout d'abord, une application web est avant tout une application dite n-tiers, c'est-�-dire r�partie sur au moins 3 "supports" ou plus : de fa�on minimaliste on a de fa�on usuelle et g�n�rale:
1) Le serveur base de donn�es, qui est un serveur relationnel et transactionn�, capable de traiter de l'information en parrall�le et qui sait tirer profit automatiquement des ressources (CPU,RAM,Disque) dont il dispose.
2) Le serveur tiers, en g�n�ral un serveur (objet) g�rant les requ�tes client http/https (apache,IIS,...). Son r�le �tant � minima, en plus de g�rer les requ�tes http/https clientes, d'identifier le client, de g�rer et s�curiser son acc�s � l'applicatif, de mettre en m�moire cache des donn�es, et de d�livrer au client les donn�es demand�es mises en forme conform�ment au cahier des charges.
3) Le client, lieu o� r�side l'IHM de l'applicatif et o� l'homme peut interagir avec les donn�es qui sont mises � sa disposition.

Que peut-on dire d'une telle architecture?
1) Sa d�finition s�mantique "n-tiers" oblige � dire que c'est une application dont les �l�ments constitutifs sont r�partis et donc d�centralis�s, contrairement � une application classique compil�e (comme le serait par exemple une application Windows : word,etc..)
2) Ainsi respecter une telle architecture afin d'optimiser ses sp�cificit�s c'est aussi d�centraliser les comp�tences et sp�cialiser les t�ches applicatives au niveau de chaque tiers : gestion et pilotage des donn�es au niveau SGBDR, contr�le des acc�s et des requ�tes applicatives au niveau de apache,IIS et PHP (ou autre) et donc au niveau du serveur objet, gestion de l'interface au niveau client.
3) rendre performant une telle architecture c'est rendre autonome chaque tiers applicatif de mani�re � ce que la seule d�pendance restante existante entre chaque tiers soit celle des donn�es, et de faire en sorte d'optimiser la bande passante en ne requ�tant pas des donn�es qui ont d�j� �t� d�livr�es.
4) Respecter l'ensemble des points pr�c�dents, c'est s'assurer de la bonne capacit� de mont�e en charge d'une telle architecture d'application.

Observations sur cette structure
- Le d�veloppement en base de donn�es �paisses est � ma connaissance aujourd'hui le seul � r�pondre � l'ensemble de ces exigences structurellement parlant.
- L'ensemble des CMS et frameworks du march� ne le respectent pas et centralisent l'ensemble de la gestion applicative au niveau du serveur tiers et donc objet (PHP/Apache, etc...), utilisent le SGBDR comme un lieu d�normalis� (au sens des bases de donn�es relationnelles) en faisant de la persistance de classe essentiellement. L� est la cause principale de leur difficult� � g�rer la mont�e et la tenue de charge applicative.

Au niveau du serveur tiers en PHP, toujours dans l'esprit de monopoliser le moins de ressources possibles, quelles sont les entit�s minimales de gestion pour faire tourner une application web?
Avant de r�pondre � cela, il est important de pr�ciser ici qu'il n'y a que deux contextes g�n�raux applicatifs :
- Le mode non connect� (ou anonyme) qui corresponds � la consultation d'un site internet normal
- Le mode connect�, qui corresponds � l'acc�s s�curis� � un back office, front office, extranet, intranet,... repr�sentant le contexte d'�tude de ce billet.

En mode connect� donc, les entit�s minimales sont au nombre de 2 et peuvent �tre repr�sent�es par deux classes : utilisateur et connection. Ces deux classes ont les particularit�s suivantes:
- Elles restent ind�pendantes du mod�le de donn�es (qui peut �tre plus complexe comme dans un ERP par exemple).
- Elles sont indispensables au bon fonctionnement applicatif et ont besoin d'�tre charg�es syst�matiquement.
- Elles ont un besoin � la fois d'�tre s�curitaire et de poss�der une emprunte m�moire minimale, cahier des charges garanti en ne pouvant les instancier qu'une seule fois dans l'application, et en respectant une encapsulation totale de l'information.
- Elles repr�sentent deux classes contr�leur dans un mod�le MVC.
- Elles doivent jouer un r�le de cache pour les donn�es qu'elles g�rent pour solliciter toujours � minima la base de donn�es.
Conclusion => Le Singleton offre tous ces avantages et peut garantir ce cahier des charges.

Nous nous retrouvons donc dans un contexte tout autre que celui expos� dans le lien du d�but de ce post, lien qui expose le pourquoi et le c�t� incontournable du pattern d'injecteur de d�pendances, dont le contexte pr�sent� reste celui de l'architecture d'une application compil�e et donc centralis�e et qui se retrouve pour "une petite application" avec un registre de plus de 20 d�pendances � charger au d�marrage pour fonctionner avec des noms aussi long que le bras, d�pendances qui peuvent d�passer les 200 sur de grosses applications, alors qu'ici on en a besoin que de deux +1 voire 2 (grosses applications) pour la gestion du module courant de consultation.

La diff�rence est d�j� d�mesur�e, les ressources monopolis�es non comparables...

En ce qui concerne les d�pendances cach�es par le singleton.
Dans une telle architecture web lorsque le mod�le MVC est utilis�, les d�pendances "cach�es" par le contr�leur singleton ne sont pas un myst�re : il ne peut y en avoir que 2 types possibles : une d�pendance de vue et une d�pendance de mod�le. Ni plus, ni moins. L'argument qu'elles soient "cach�es" n'en est de plus pas un, car il est tr�s facile de les isoler au sein du contr�leur:
Code : S�lectionner tout - Visualiser dans une fen�tre � part
$reponse=$this->MODEL('udpate_sales_permonth',$params);
L'approche est d�terministe et reste affect�e dynamiquement � l'ex�cution, ce qui reste tr�s facilement maintenable et extensible � souhait sans modification ni mise � jour structurelle du code. D�s qu'une nouvelle fonctionnalit� doit �tre impl�ment�e, il suffit de cr�er la classe mod�le correspondante et de l'appeler via le contr�leur lorsque applicable. Tout reste isol� et facilement maintenable.

Le ma�tre mot est de savoir adapter l'architecture de son application � ses contraintes d'exploitation et m�tier, et non pas faire de la technique pour de la technique, ni de vouloir imposer un mod�le applicatif lorsque celui-ci n'est pas pertinent pour le besoin et les contraintes exprim�es, pour une quelconque raison hors contexte.

Concernant le scope global du singleton
Pour commencer, contrairement � une variable globale qui est d�clar�e et qui monopolise des ressources d'une mani�re permanente, le singleton ne l'est que si il est instanci�.
Concernant l'exploitation du singleton dans le contexte expos� dans ce billet, c'est-�-dire pouvant servir de cache, il est l�gitime que celui-ci puisse �tre accessible globalement dans l'application. Il faudra donc �viter pour cet usage de rendre la m�thode publique __wakeup du singleton priv�e sous peine de d�sactiver la possibilit� de l'utiliser comme cache pour les donn�es qu'il contr�le, comme je l'ai d�j� aper�u dans certains billets sur le net. Ensuite, je rappelle qu'un singleton peut �tre d�fini dans un namespace donn� ce qui peut r�duire son scope de d�finition, et bien qu'�tant global � l'applicatif, il pr�serve l'encapsulation, ce qui reste essentiel pour un contr�leur.
Pour les d�veloppeurs issus du C, Java, etc... qui continuent � penser que d'avoir des objets globaux � l'application c'est pas propre, ou qui ont d'autres qualificatifs en t�te, je trouve bizarre qu'ils tiennent de tels propos lorsqu'il sont les premiers (et � juste titre) � compiler leur biblioth�ques de fonctions ou certains contr�leurs dans une dll et � d�clarer celle-ci comme d�pendance globale au sein de leur projet. Je reste � votre disposition pour en discuter plus en d�tail.

Concernant l'aspect "abstraction � la couche de donn�es"
J'ai vu certains qui utilisent le pattern DI (Dependency Injection) pour cr�er une couche d'abstraction aux donn�es, et qui par exemple font un code pour acc�der aux donn�es via PDO, un autre via mysqli, un autre via ODBC etc... C'est du n'importe quoi pour une seule raison :
=> PDO, mysqli, etc... repr�sentent d�j� � eux seuls une couche d'abstraction aux donn�es. Il ne sert � rien de cr�er une abstraction sur de l'abstraction.
S'il est recommand� d'utiliser PDO avec PHP, certains en font fi. Pourtant on peut travailler avec PDO sur du SQL Server en installant le driver natif pour SQLServer, idem pour postgreSQL, pareil pour MySQL, etc...

De plus, Certains font comme tous les CMS et frameworks openSource du march� leur ont montr�, et tuent les performances de leur application (en centralisant la gestion donn�es au niveau tiers) en faisant/utilisant soit :
- un ORM pour acc�der � leur donn�es
- en d�veloppant eux-m�me un niveau d'abstraction idiot en construisant des requ�tes g�n�riques via des objets
Code : S�lectionner tout - Visualiser dans une fen�tre � part
$GET_ARTICLES->query('SELECT * FROM articles');
=> au lieu de le faire des biblioth�ques m�tier par SGBDR appelant des proc�dures stock�es ou vues sur le SGBDR, et en optimisant la mise en forme des param�tres en fonction du SGBDR cibl� (utilisation d'arrays sur postgreSQL, etc...) et en ne requ�tant seulement les donn�es demand�es.

Voil� j'esp�re que ce petit tour d'horizon vous aura aid� � y voir plus clair.
Alors le Pattern Dependency Injector a ses raisons d'�tre, et dans une architecture web n-tiers de type MVC, reste � utiliser au cas par cas lorsque les contraintes l'exigent.

Bonne lecture � vous :)