jeudi 22 novembre 2007

TP: Crud Create-Retrieve-Update-Delete


Architecture
L'application est vue comme un modèle de données du domaine fortement structuré et typé et couplé.

Cette couche métier à caractère statique côtoie une couche d'interface utilisateur (swing, html, jsp, dans notre cas jsf), ainsi qu'une couche applicative constituée par les contrôleurs, à caractère dynamique.

Ce modèle du domaine est bien découplé des deux autres couches, ainsi que des couches techniques (persistance par exemple).

Dans le cas où le modèle est connecté avec un ou plusieurs modèles externes, cette connection s'effectuera au travers d'une API consitutée d'interfaces.

Les classes métier comportent des règles-métier de base (l'âge d'un personne ne peut être négatif....)
Les contrôleurs comportent des règles métier applicatives (on ne peut changer de département pour telle adresse, le solde du compte ne peut être inférieur à une limite autorisée).

Développer une application revient à concevoir et à coder le modèle statique, la mécanique navigationnelle (Crud = create-retrieve-update-delete), les règles de gestion et les exceptions-métier, l'interface utilisateur, après avoir choisi une infrastructure technique (jsf dans notre cas) et une solution de persistance du modèle (jdbc, hibernate, ejb, etc...), conformément aux spécifications fonctionnelles qui auront été rédigées pour satisfaire le besoin.

Organisation du code

La première tâche est de structurer le projet.
Les classes de l'application se situent dans un package bank. Les classes du modèle dans un package bank.model. Les exceptions métier ont également un package réservé, ainsi que les contrôleurs.

L'organisation du code proposée est le fruit d'un parti-pris architectural, et n'est en rien obligatoire. Cependant, cette méthode met en évidence le modèle MVC sous-jacent à JSF, et tend à établir une bonne pratique.

Les contrôleurs sont au nombre d'un par entité, ils ont tous la même structure.
Les composants graphiques sont extraits des contrôleurs et placés dans une classe View (package bank.view).
Les vues sont génériques, il ne doit pas y avoir d'adhérence au modèle, sauf décision de conception différente.

Afin d'éviter l'adhérence au modèle, on utilise éventuellement des classes utilitaires afin de peupler certains composants (voir classe KeyValuePair par exemple).

Les classes du modèle ne doivent comporter aucune adhérence aux contrôleurs ni aux vues. Vérifiez le en examinant la liste des imports.

L'organisation proposée n'est pas totalement aboutie. Il sera nécessaire, par la suite, de déresponsabiliser les contrôleurs des fonctionalités de navigation dans le modèle(crud). Ces fonctionnalités seront, plus tard, confiées à des classes DAO (Data Access Object), les contrôleurs conservant simplement une fonction d'aiguilleur.

Structure du projet


Interface utilisateur





Exemples de code

dans bankControler:

dans ListView


la classe KeyValuePair

dans bankForm.jsp


corrigé ici

0 commentaires: