On appelle cela une couche d’abstraction qui sert intermédiaire entre la base de données et l’application. Le but est de modéliser le schéma d’une base de données sous forme de classes et d’objet pour ne pas travailler avec le langage SQL et les drivers de base de données car il est évident qu’une application écrite de A à Z avec des mysql_connect() et mysql_query() ne sera pas très robuste et migrera difficilement vers un autre SGBD comme Postgre ou Oracle…

Zend_Framework fournit un outil nommé Zend_Db_Table pour gérer à l’aide d’un système de DAO (Database Access Object) les transactions avec les bases de données.

Nous allons voir dans un premier temps comment configurer Zend_Framework pour mettre en place ce système :

Configuration du fichier Application.ini :

;database configuration
resources.db.adapter = "pdo_mysql"
resources.db.params.host = "localhost"
resources.db.params.username = "root"
resources.db.params.password = ""
resources.db.params.dbname = "announcements"
resources.db.params.date_format = "YYYY-MM-ddTHH:mm:ss"
resources.db.isDefaultTableAdapter = true

Il faut spécifier dans le « Application.ini » les paramètres pour accéder à votre base de données, il faut y spécifier l’adresse de la base, le type (pdo_mysql, postgre, sqllite, oci8, mssql, …), l’utilisateur avec le mot de passe, le nom de la base de données et le format de date et heure.

Ecrire les classes d’accès aux données (utilisation de Zend_Db_Table) :

Il nous faut maintenant écrire les classes permettant de modéliser les tables de la base de données pour cela on va utiliser Zend_Db_Table pour générer une classe permettant d’accéder à la table « posts  » de notre application :

On créer tout d’abord un dossier « models » dans notre répertoire /application avec un dossier DbTable dedans.

Nous allons générer un fichier Post.php :

Tout d’abord, on crée une classe dérivée de Zend_Db_Table que l’on nommera avec la syntaxe suivante : Model_DbTablr_NomDeLaTable en spécifiant le nom extact dans l’attribut protégé « name » :

Ensuite il ne reste plus qu’à écrire les méthodes qui permet les transactions avec les bases de données, je recommende fortement d’utiliser une méthode pour chaque transaction plutôt que de les écrire dans le contrôleur, on est dans un design-pattern MVC !

Voici le prototypage de notre classe et l’implémentation de notre classe :

fetchRow('id = '.(int)$id);
		if (!$row)
		{
			// On lance une exception en cas d'erreur
			throw new Exception ("Erreur, l'enregistrement $id n'existe pas !");
		}
		// On retourne le résultat sous forme de tableau
		return $row->toArray();
	}

	/**
	 * Ajoute un article en base de données
	 * @param $values
	 * @return unknown_type
	 */
	public function addPost ($values)
	{
		// On enregistre les valeurs sous forme de tableau [champs] => valeur
		$result = $this->insert($values);
		if (!$result)
		{
			throw new Exception ("Erreur impossible d'enregister");
		}
	}

	/**
	 * Met à jour un article en base de donneés
	 * @param $values
	 * @return unknown_type
	 */
	public function updatePost ($id,$newValues)
	{
		$result = $this->update($newValues, 'id = '.(int)$id);
		if (!$result)
		{
			throw new Exception ("Erreur impossible de mettre à jour");
		}
	}

	/**
	 * Supprime l'article $id
	 * @param $id
	 * @return unknown_type
	 */
	public function removePost ($id)
	{
		$result = $this->delete('id = '.$id);
		if (!$result)
		{
			throw new Exception ("Erreur impossible de supprimer");
		}
	}

	/**
	 * Requête avec jointure pour récupérer les 5 premiers
	 * articles avec les données de la table auteur en jointure
	 * et qui ont leur status publié
	 * @return unknown_type
	 */
	public function findPostsWithAuthorsInformations ()
	{
		$db = $this->getAdapter();

		$select = $db->select()
					 ->from('post')
					 ->joinInner('author', 'post.author_id = author.id')
					 ->where('status = "published"')
					 ->limit(5);
		$query = $select->query();
                $result = $query->fetchAll();

		return $result;
	}
}
?>

Pour appeler cette classe dans le contrôleur rien de plus simple, on instancie un objet « $model » et pis on appelle les méthodes que l’on a implémentée :

< ?php
	class PostController extends Zend_Controller_Action
	{
		public function init ()
		{
			// On fait rien
		}

		public function testModelAction ()
		{
			$model = new Model_DbTable_Post();

			// Ajout
			$model->addPost(array('title' => 'test', 'content' => 'ceci est mon premier post', 'status' => 'publised'));

			// Requête
			$this->view->posts = $model->findPostsWithAuthorsInformations();

			// Suppression
			$model->removePost(2);

		}
	}
?>

La prochaine fois nous verrons le fonctionnement des formulaires avec Zend_Form

Pour cela Zend propose une structure très standard et très connue des développeurs, le design-pattern MVC (Modèle Vue Contrôleur).

Petit rappel sur le modèle MVC : il consiste à séparer les trois parties fondamentales d’une application finale.

La première regroupe les traitements et l’intégritée des données. Elle s’occupe généralement des interactions avec la base de données avec une couche d’abstraction que nous verrons dans un prochain tutoriel.

La vue n’est autre que la partie interface graphique de l’application, c’est l’interface avec l’utilisateur et elle ne doit exercer aucun traitement.

Le contrôleur est l’intermédiaire entre les 2 autres couches, il récupère les actions de d’utilisateurs et déclenche les traitements à effectuer.

Voici la couche Vue de notre application Zend de départ, on remarque qu’elle contient exclusivement le code HTML et le CSS ainsi que des variables  qui ne servent qu’à afficher des données :

La couche contrôleur se comporte sous la forme d’une classe dérivée de Zend_Controller_Action, elle doit être nommé sous la forme NomController et il en est de même pour le fichier qui la contient. Dans notre IndexController, nous avons 2 méthodes par défaut : init() et indexAction(). La méthode init() est l’action à exécuter par défaut avant n’importe quelle autre action. On peut y mettre des traitements pour récupérer des variables en paramètres ou en session par exemple. La méthode IndexAction() est la méthode centrale du contrôleur, il s’agit de la page par défaut. Les vues du contrôleur doivent être regroupées dans un même répertoire et doivent porter le même nom que l’action avec l’extension *.phtml pour les templates.

Les urls fonctionnent de la façon suivante : racine/index.php/contrôleur/action

Maintenant que nous sommes à l’aise avec le contrôleur et la vue, nous allons mettre en place un template principal qui sera la base graphique de notre application : il s’agit d’un layout.

On commence d’abord à paramètrer notre application, pour cela on se rend dans le application.ini dans le répertoire configs :

On y définit le répertoire, où nous allons placer nos fichiers de mise en page, par convention on choisira le répertoire application/layouts/scripts.

En suite nous allons modifier le Bootstrap et surcharger la méthode _initDoctype() qui définiera le doctype de notre page Web.

Nous pouvons maintenant créer le layouts.phtml dans le répertoire /layours/scripts et y insérer les balises de contenue.

On pourra étendre ce layout à plusieurs fichiers comme un header, un footer, une sidebar par exemple.

C’est fini pour la structure MVC de Zend et la création de layouts, nous verrons dans le prochain tutoriel comment se comporte la couche modèle et les interactions avec la base de données et nous ferons notre première application CRUD (Create Read Upload Delete).

]]> http://www.alexandre-julien.com/php/zend-framework-tutoriel-2-layouts-et-design-pattern-mvc/feed/ 0