Requêtes et récupération de données
Ce chapitre expose les "normes" internes d'écriture pour la construction de modules et l'écriture des transactions vers la base données.
Règles sur le modèle de données
Entités constitutives du MPD du module
Le modèle de donnée de la plupart des applications Web identifie des "objets" principaux dont le site est une interface de gestion. Il est d'usage, pour développer un module :
-
d'identifier clairement l'identité du module > cette identité donne lieu à la création d'une entité principale dans la base de donnée (exemple : "forum").
-
d'identifier la ou les entités "éléments" gérés par l'entité module. Une règle efficace est de déterminer quelle est l'entité "élément" principale, c'est-à-dire, l'entité individuelle dont le module est un "container" et de la nommer comme le module suivi du suffixe "item" (par exemple : forumitem), ce qui adopte une lecture sémantique suivante : l'entité "moduleitem" est un contenu du container "module".
-
pour que les tables d'un module apparaissent ensemble dans la liste des tables de la plate-forme, il est souhaitable que toutes les tables annexes du module soient préfixées du nom du module. Par exemple :
|
default_catalog
|
entité principale "container" : catalogue produits |
|
default_catalogitem |
entité contenu principale : élément de catalogue |
|
default_catalogcategory |
entité annexe : les catégories d'indexation du catalogue |
Nommage et choix des attributs
Les attributs sont nommés en minuscule par des mots de préférence simples, sans redondance avec l'entité "table". Les mots composés peuvent être utilisés lorsque la sémantique de l'attribut ne pourrait éviter une confusion avec d'autres attributs.
La clef primaire est, sauf cas particuliers (tables de relation n:n, cas particuliers de clefs composites ou textuelles), la première colonne de la table et porte le nom Id :
Id INTEGER PRIMARY_KEY NOT NULL auto_increment,
Elle peut être auto-incrémentale si nécessaire et peut prendre tous les types entiers admis, suivant la plage probable de nombre d'objets.
Règles sur le source PHP
Séquence d'appel de données (SELECT)
Séquence type :
|
$query = "
SELECT
...
";
$results = db_execute($query);
$objects = array();
while($anObject = mysqli_fetch_object($results)){
$objects[] = $anObject;
} |
Explication du "code style" :
-
La requête à exécuter est TOUJOURS placée dans une variable ($query, $query1, etc.).
-
La requête est passée à la fonction db_execute qui est une variante propriétaire de mysqli_query intégrant des commutateurs d'affichage de déboggage. La requête produit un tableau $results (requête sur attributs) ou un tableau $result en cas de résultat unique (requête sur clef primaire). L'utilisation de $results ou de $result dépend donc de l'écriture de la requête.
-
Un tableau d'objets PHP est initialisé, d'un nom significatif par rapport à l'objet de donnée matérialisé en mémoire.
-
Les objets résultats de requête sont transférés dans le tableau.
La règle Controller-Vue interdit que tout affichage soit généré au moment de la matérialisation des objets de donnée en mémoire php. On se rappelle que la stratégie dominante est :
-
on matérialise l'ensemble des données nécessaires à la production de la vue dans des structures de donnée mémoire.
-
on réalise la vue par la suite, en explorant les structures mémoires matérialisées :
|
...
// bien plus loin
...
foreach($objects as $anObject){
?>
<!- do something in HTML -->
<?
}
?> |
|
