WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Développement d'une application de cartographie interactive sur internet.

( Télécharger le fichier original )
par Khadim Mbacké
Université Jean Monnet de Saint-Etienne - Master 2 Système d'Information Géographique 2015
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2. Symfony2 et Doctrine

La mise en place du Framework* Symfony2 permet d'architecturer tout le côté serveur de l'application, c'est-à-dire tous les processus entre le côté client et la base de données. Son installation se fait en ligne de commande dans ce projet. Pour le détail de l'installation, voir le site de Symfony24(*).

Symfony2 permet de structurer de manière fonctionnelle un projet par l'intermédiaire des Bundles*(voir Annexe III) qui sont même temps interdépendants dans un projet et qui peuvent être génériques afin d'être portables dans un autre projet. Dans le projet câbles, trois bundles ont été créés:

CablesBundle : squelette de base qui gère toutes les fonctionnalités de l'application.

ExtBundle: gestion spécifiques des tables dictionnaires.

UsersBundle : gestion des tables utilisateurs. L'évolution de l'application au niveau régionale fait qu'elle sera utilisée par des partenaires multiples avec des profils d'accès différents aux fonctionnalités et aux données. Ce bundle permet de gérer tout le processus durant la connexion d'un utilisateur sur l'application.

Outre la structuration d'un projet, Symfony2 permet de facilement établir la connexion avec la base de données par la configuration d'un fichier unique.

La communication entre Symfony2 et la base de données se fait par l'intermédiaire de l'ORM* Doctrine (cf. schéma : #4,5). Cette bibliothèque indépendante permet de gérer le modèle de données (la base de données). Son but est de créer une image des tables et des vues de la base appelée mapping (voirAnnexe IV) dans Symfony2 pour éviter l'utilisation des requêtes brutes. A partir de ce mapping, Symfony2 créé automatiquement des fichiers (classes d'entités) contenant des objets qui permettent de manipuler les données entre l'utilisateur et la base de données.

Certaines tables métier contiennent des informations géométriques (point, ligne, polygone). De base, Symfony2 via Doctrine ne permet pas gérer ce type de données. C'est pourquoi une extension supplémentaire  a été installée: Doctrine2Spatial. Elle permet à Symfony2 de reconnaitre et à de traiter la géométrie venant de la base de données.

3. Requêtes et réponses HTTP*

L'application a aussi bien été développée sur le modèle d'architecture MVC* coté serveur (Symfony2) et coté client (AngularJS), ce qui facilite la communication entre les deux Framework* mais aussi le développement sans avoir à développer tout le processus classique de communication HTTP* entre le côté client et côté serveur.

Le modèle MVC* permet de cloisonner le développement d'une application. Il s'agit d'une bonne pratique de développement, le travail qui traite l'apparence et l'interface du site (Vue, cf. schéma : #8) sera indépendant de la logique métier (Modèlecf. schéma : #3), lui-même indépendant du traitement des requêtes de l'utilisateur (Contrôleur, voirAnnexe V) sans perdre toute la chaine du fonctionnement de l'application.

Quand l'utilisateur fait une demande pour afficher des données (cf. schéma : #1), cette demande se fait sous forme d'adresse URL*. Ces adresses sont définies dans le routage qui permet d'avoir des URL*très simples (par exemple /cables/zonesensibles). Les routes sont interprétées par les contrôleurs qui vont traiter l'information sous forme de demande (requêteHTTP*cf. schéma : #2) à la base de données et le résultat renvoyé (Response HTTP* cf. schéma : #7) par cette dernière.

Il y a plusieurs formats de requête HTTP* ou réponse HTTP*mais dans le cadre de l'application, c'est le format GeoJSON ou JSON* qui a été utilisé respectivement selon que les données contenaient ou pas des informations sur la géométrie.

Le format JSON*(ou GeoJSON) a été utilisé car la combinaison de son format (texte) et d'un encodage (sérialisation) des données permet une communication performante entre le côté client et le côté serveur, particulièrement pour les informations contenant de la géométrie qui augmente le volume du flux JSON*.

* 4http://symfony.com/http://symfony.com/fr/doc/current/book/installation.html

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Ceux qui rêvent de jour ont conscience de bien des choses qui échappent à ceux qui rêvent de nuit"   Edgar Allan Poe