Vincent wrote:
Bonjour,
NB : vu la question, xpost et fu2 fr.comp.objet
Je cherche à avoir une méthode de dev qui me permet d'avoir un appli la
plus maintenable possible et la plus évolutive possible. Je me pose donc
la question suivant quand on utilise delphi (mais c valable pour d'autre
langage) :
Prenons le cas simplifié d'une gestion de client.
j'ai 2 possibilités:
Principe 1 :
- Définition d'une classe TClient (unité Client.pas)
Propriété publiées :
CodeClient
Raison Sociale
ClientDataset
etc...
méthodes :
Edit;
Delete;
Post;
etc...
- Définition d'un écran
l'écran étant appelé avec comme paramètre l'objet client à modifier
ou nil pour indiquer une création de nouveau client.
=> les requêtes SQL sont donc gérés par la class Tclient et donc inconnu
de l'écran. par contre, une rubrique d'un client doit être défini 2 fois
(écran + class) ce qui donne un double travail
Principe 2:
Pas de classe Tclient.
Définition d'un écran.
Gestion des données directement dans l'écran.
(exemple, clic sur Enregistrer, le bouton execute la requete UPDATE)
Le principe 2 me semble un peu plus rapide à mettre en place, mais en
même temps j'ai l'impression que le principe 1 est peut-etre celui qu'il
faut utiliser pour avoir à long terme une appli maintenable.
A votre avis, que faut-il priviligier et pourquoi ? Existe t'il une
autre méthode plus correct ?
La seconde méthode ne convient que pour des CRUD très basiques. Dès
qu'il y a une logique métier un tant soit peu complexe, ça devient un
cauchemard (je parle par expérience personnelle).
La mise en oeuvre d'une architecture OO avec une couche métier (première
méthode) est plus complexe au moins au début, mais, si correctement
réalisée, apporte bien plus de souplesse. En général, une solution de
ce genre se base sur le modèle MVC - Modèle Vue Controleur.
Le modèle est la couche métier à proprement parler (ici TClient et
autres objets liés (adresses etc)). Elle est supposée être indépendante
du reste (vues et controleurs).
La (les) vue(s) s'occupe d'afficher une représentation possible du
modèle et les actions possibles. C'est, dans ton cas, les différents
écrans de l'interface graphique. Cette partie n'a pas d'autre
responsabilitées que l'affichage. Les vues sont bien sûr dépendantes du
modèle.
Le(s) controleur(s) se charge de répondre aux actions de l'utilisateur.
Il est généralement appelé par la vue (évènement de l'interface
graphique), et son rôle principal est de traduire ces actions en appels
appropriés sur le modèle.
On peut bien sûr avoir des vues et des contrôleurs 'composés', ie : une
fenêtre composée d'un menu (une vue et son controleur), d'une liste de
clients (une vue et son controleur) et d'une fiche client (une vue et
son controleur).
La plupart des GUI toolkits actuels implémentent déjà toute la partie
'bas niveau' du contrôleur (transformer un click de souris à un endroit
de l'écran en évènement). Dans le cas d'applis 'pipeline', on a (trop)
tendance à mettre en vrac logique métier et logique de présentation dans
les gestionnaires d'évènement. Dans notre cas, on se contentera
d'appeler une classe controleur appropriée.
Dans le cas d'un 'client lourd' (ce qui est le cas du MVC originel),
c'est le modèle qui notifie ses vues des changements d'état pour que
celles-ci puisse se rafraîchir. Afin de garantir le découplage entre le
modèle et les vues, on utilise canoniquement le pattern Observer (la doc
ne manque pas à ce propos).
Bref, regarde du côté de MVC et des design patterns (en commençant par
le GoF, qui est probablement un des meilleurs ouvrages sur l'OO). Une
ressource intéressante aussi est Patterns of Enterprise Application
Architecture de Fowler:
http://www.amazon.com/gp/product/0321127420/103-6336884-0927018?v=glance&n=283155
http://www.martinfowler.com/eaaCatalog/
C'est plus orienté web que client lourd, mais l'essentiel y est.
Merci.
HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
