OVH Cloud OVH Cloud

MVCly correct (long) ?

2 réponses
Avatar
Zouplaz
Bonjour, je tente de comprendre les architectures MVC avec une mise en
oeuvre semi-personnelle à savoir sans utiliser un framework type struts
mais en m'appuyant sur velocity et hibernate.

Pour l'instant j'ai bien d'un côté des "vues" (les scripts velocity), de
l'autre un "modèle" (les classes objets persistées par hibernate), et
ensuite un "controleur" (mon servlet) qui instancie des "modules" (en
fonction d'actions)...

Bon, je ne sais pas si c'est MVC ou pas mais par contre il y a une
question à laquelle j'ai bien du mal à répondre.

Actuellement, je crée autant de fichiers .vm qu'il y a de formulaires.
La vue, son aspect visuel est totalement dissociée du reste et je peux
même travailler avec un outil wysiwyg comme Dreamweaver. Bien, jusque là
tout baigne.

Là où ça commence à coincer c'est lorsque j'envisage la création d'un
nombre important de formulaires (important est variable selon les points
de vues, pour moi une dizaine c'est déjà important).
Comme chaque formulaire est dans un template, je ne peux pas espérer
partager certaines fonctionnalités entre tous.

Exemple, imaginons que j'utilise un éditeur html online dans 5
formulaires.
Ce type d'objets est trop complexe pour être exploité via une macro
insérée dans le template (et en plus j'ai horreur des macros).
Donc, j'ai 5 templates avec 5 fois la même chose ou presque.

Dans une vie antérieure en PHP j'avais montée une librairie de classes
qui prenait le chemin inverse : rien n'était éditable avec un outil
externe, tout était instancié dans le code, comme une application Swing.
En résumant, ça donnait des choses du genre :

form = new Form()
field = new Field()
nom = new TextInput()

field.add(nom)
form.add(field)
page.add(form)

page.draw()

Et j'aimais bien cette manière de procéder car si un objet était
amélioré, toute l'application en bénéficiait instantanément.

J'ai vu que tous les gros frameworks proposent des composants
réutilisables (au minimum des contrôles par exemple) je pourrais donc
faire la même chose et réimplémenter en java mes classes controles PHP
et ce sans aller à l'encontre de la philosophie MVC.

Par contre, le problème me semble moins clair si j'imagine aller jusqu'à
des objets Page, Form, Field...

Est-ce que des objets de ce type doivent être exploités uniquement dans
les vues ? Si oui, quel intérêt de continuer à utiliser des templates
alors qu'il n'y a plus de tags html et que les scripts ne contienent plus
que des références à des méthodes ou propriétés d'objets ?
Pourquoi ne pas faire la même chose dans une classe java dans ce cas ?


Donc, en résumé je vois trois possibilités :
- en rester aux templates et concevoir des controles de base (text input,
dropdown, etc)
- implémenter également des objets plus complexes (formulaires, listes,
champs de formulaires, controles de validation, etc) et les exploiter
QUAND MEME dans un template
- faire la même chose mais sans les templates


Dernier point, je parle ici de web applications avec des structures
toujours identiques (des listes, des formulaires). Si une application
doit avoir une interface public (un site donc), là l'usage des templates
s'impose à cause de la richesse de la mise en page et des différences
entre chaque projets.

Voila, dites moi ce que vous pensez de tout ça

Merci

2 réponses

Avatar
Jaypee
Bonjour, je tente de comprendre les architectures MVC avec une mise en
oeuvre semi-personnelle à savoir sans utiliser un framework type struts
mais en m'appuyant sur velocity et hibernate.

...


Dernier point, je parle ici de web applications avec des structures
toujours identiques (des listes, des formulaires). Si une application
doit avoir une interface public (un site donc), là l'usage des templates
s'impose à cause de la richesse de la mise en page et des différences
entre chaque projets.

Voila, dites moi ce que vous pensez de tout ça

Merci
Même si je suis hors-sujet, je suggèrerais quand même de jeter un oeil

sur Ruby On Rails.

C'est pas du Java, c'est du Ruby. Mais a celà un gros mérite, c'est
hyper concis, idéal pour du maquettage MVC. Libre ensuite à vous ensuite
de porter le résultat sur la plateforme cible. Rails a un composant
distinct pour chacune des lettres C, V, mais aussi M. Une video existe
où l'on voit la construction d'une appli (un Bulltin Board, un forum en
quelque sorte) pendant le temps de la démo (10 minutes environ)

Comprendre le pattern MVC et designer une appli en même temps me
semblent un plan ambitieux. Au bout de deux ans, je commence à être plus
à l'aise avec Struts, mais la route fût longue ...
J-P

Avatar
David JOURAND
Le must du MVC web en java : SpringFramework
(http://www.springframework.org/) et le livre de son auteur Rod Johnson
"Expert One-on-One J2EE Development without EJB"

SpringFramework s'interface avec beaucoup de chose dont Velocity et
Hibernate...

Indsipensable...

--
David Jourand