Thông tin tài liệu
238 Chapitre 5. Organisation du développement on ne visait pas une application portable. Comme on le voit avec la solution adoptée ci-dessus, la modification est d’une part tout à fait mineure, d’autre part invisible pour l’application qui se contente d’appeler le générateur quand elle en a besoin. 5.3.3 PDO, l’interface générique d’accès aux bases relationnelles La dernière chose à faire pour assurer la portabilité de l’application est d’utiliser une interface normalisée d’accès à la base de données, qui cache les détails des API propres à chaque système, comme le nom des fonctions, l’ordre des paramètres, le type du résultat, etc. Depuis la version 5.1 de PHP cette interface existe de manière standardisée sour le nom PHP Data Objects (PDO). PDO ne dispense pas des précautions syntaxiques présentées ci-dessus, mais fournit des méthodes d’accès standardisées à une base de données, quel que soit le système sous-jacent. PDO ne présente aucune difficulté maintenant que vous êtes rôdés à l’interface PHP/MySQL. Voici un exemple similaire au script ApplClasseMySQL.php, page 119, pour interroger la table FilmSimple. Exemple 5.9 exemples/ApplPDO.php : Utilisation de PDO <?xml version=" 1.0 " encoding=" iso −8959−1"?> <!DOCTYPE html PUBLIC " −/ /W3C / / DTD XHTML 1 . 0 S t r i c t / / EN " "http ://www.w3. org /TR/xhtml1/DTD/xhtml1−strict .dtd"> <html xmlns="http ://www.w3. org/1999/xhtml" xml:lang=" fr "> <head> <title >Interface PDO</title > < link rel=’stylesheet ’ href="films . css" type="text/css" /> </head> <body> <h1>Illustration de l ’interface PDO</h1> <?php /∗∗ ∗ Exemple de programmation avec PDO ∗ / require_once ("Connect.php") ; try { // On se connecte $bd = new PDO( ’ mysql : host= ’ .SERVEUR. ’ ; dbname= ’ .BASE, NOM, PASSE ); // On exécute une requête $resu l tat = $bd−>q u ery ("SELECT ∗ FROM FilmSimple") ; // On récupère les lignes while ($film = $resultat−>fetch (PDO::FETCH_OBJ)) { 5.3 Portabilité multi-SGBD 239 echo "<b>$film−>titre </b>, paru en $film−>annee , réalisé " . "par $film−>prenom_realisateur $film−>nom_realisateur.<br />\n"; } // Et on ferme le curseur $resultats−>closeCursor() ; } catch(Exception $e) { echo ’ Erreur PDO : ’ . $e−>getCode . " −− ".$e−>getMessage() .’<br/>’; } ?> </body> </html> On commence donc par instancier une connexion avec la base de données. Il s’agit d’un objet de la classe PDO, dont le constructeur prend en entrée les paramètres habituels : serveur, nom de la base, et compte de connexion. On précise également que l’on se connecte à MySQL. C’est le seul point à modifier pour utiliser un autre système. On peut ensuite exécuter une requête d’interrogation avec la méthode query(). Elle renvoie un objet instance de PDOStatement qui sert à parcourir le résultat avec la méthode fetch(). On passe à cette dernière méthode le format (objet ou tableau) dans lequel on souhaite obtenir le résultat. Tout est donc semblable, à quelques détails près, à ce que nous utilisons depuis plusieurs chapitres pour MySQL. Quand on veut protéger par un échappement les données à insérer dans une requête, on utilise la méthode quote(). Notez égale- ment que PDO distingue les requêtes d’interrogation, exécutées avec query(),des requêtes de mise à jour pour lesquelles on utilise exec(). Si vous voulez créer une application portable multi-SGBD, l’apprentissage de PDO ne pose aucun problème. Nous y revenons de manière plus complète dans le cadre de la programmation avec le Zend Framework, chapitre 9. Pour le site W EB- S COPE, nous continuons à utiliser la classe abstraite BD, conçue dans le même but, et dont la réalisation est décrite dans le chapitre 3. Rappelons que cette classe fixe les méthodes communes à tous les systèmes, et se décline en sous-classes implantant ces méthodes pour chaque système utilisé. Rien n’empêche de revoir l’implantation de cette classe avec PDO, de manière transparente pour le reste de l’application. Nous pouvons donc considérer que notre application est portable d’un SGBD à un autre. Architecture du site : le pattern MVC 6 Ce chapitre est consacré au « motif de conception » (design pattern) Modèle-Vue- Contrôleur (MVC). Ce pattern est maintenant très répandu, notamment pour la réalisation de sites web, et mène à une organisation rigoureuse et logique du code. Un des objectifs est la séparation des différentes « couches » constituant une application, de manière à pouvoir travailler indépendamment sur chacune. Il devrait par exemple toujours être possible de revoir complètement la présentation d’un site sans toucher au code PHP, et, réciproquement, le code PHP devrait être réalisé avec le minimum de présupposés sur la présentation. La question de l’évolutivité du code est elle aussi essentielle. Un logiciel évolue toujours, et doit donc être modifiable facilement et sans dégradation des fonctions existantes (régression). Enfin, dans tous les cas, l’organisation du code doit être suffisamment claire pour qu’il soit possible de retrouver très rapidement la partie de l’application à modifier, sans devoir ouvrir des dizaines de fichiers. Ce chapitre présente le MVC dans un contexte pratique, en illustrant les diffé- rentes composantes par des fonctionnalités intégrées au site W EBSCOPE.Defait,à la fin du chapitre nous disposerons d’un cadre de développement MVC dans lequel l’ensemble du site prendra place. Pour des raisons de clarté et d’introduction à des concepts parfois complexes, le MVC présenté ici vise davantage à la simplicité et à la légèreté qu’à la richesse. L’apprentissage de solutions plus complètes destinées à des développements à grande échelle devrait en être facilité. J’espère vous convaincre ainsi de l’intérêt de cette approche pour toutes vos réalisations. 242 Chapitre 6. Architecture du site : le pattern MVC 6.1 LE MOTIF DE CONCEPTION MVC Cette introduction au MVC est volontairement courte afin de dire l’essentiel sans vous surcharger avec toutes les subtilités conceptuelles qui accompagnent le sujet. Je passe ensuite directement aux aspects pratiques avec la réalisation « maison » du MVC que nous allons utiliser pour implanter notre site. 6.1.1 Vue d’ensemble L’objectif global du MVC est de séparer les aspects traitement, données et présentation, et de définir les interactions entre ces trois aspects. En simplifiant, les données sont gérées par le modèle, la présentation par la vue, les traitements par des actions et l’ensemble est coordonné par les contrôleurs. La figure 6.1 donne un aperçu de l’architecture obtenue, en nous plaçant d’emblée dans le cadre spécifique d’une application web. Vue Modèle requête HTTP réponse HTTP Contrôleur A Contrôleur B Action A1 Contrôleur frontal Action B1Action A2 Figure 6.1 — Aperçu général d’une application MVC La figure montre une application constituée de plusieurs contrôleurs, chacun constitué d’un ensemble d’actions. La première caratéristique de cette organisation est donc de structurer hiérarchiquement une application. Dans les cas simples, un seul contrôleur suffit, contenant l’ensemble des actions qui constituent l’application. Pour de très larges applications, on peut envisager d’ajouter un niveau, les modules, qui regroupent plusieurs contrôleurs. Chaque requête HTTP est prise en charge par une action dans un contrôleur. Il existe un contrôleur frontal qui analyse une requête HTTP, détermine cette action et se charge de l’exécuter en lui passant les paramètres HTTP. Au niveau du déroulement d’une action, les deux autres composants, la vue et le modèle, entrent en jeu. Dans le schéma de la figure 6.1, l’action A 1 s’adresse au modèle pour récupérer des données et peut-être déclencher des traitements spéci- fiques à ces données. L’action passe ensuite les informations à présenter à la vue qui se charge de créer l’affichage. Concrètement, cette présentation est le plus souvent un document HTML qui constitue la réponse HTTP. . l’organisation du code doit être suffisamment claire pour qu’il soit possible de retrouver très rapidement la partie de l’application à modifier, sans devoir ouvrir des dizaines de fichiers. Ce chapitre. que cette classe fixe les méthodes communes à tous les systèmes, et se décline en sous-classes implantant ces méthodes pour chaque système utilisé. Rien n’empêche de revoir l’implantation de cette. propres à chaque système, comme le nom des fonctions, l’ordre des paramètres, le type du résultat, etc. Depuis la version 5.1 de PHP cette interface existe de manière standardisée sour le nom PHP
Ngày đăng: 06/07/2014, 00:20
Xem thêm: Pratique de MySQL et PHP- P53 pptx
