Pourquoi inventer quand on peut copier ? Pourquoi refaire quand on peut réutiliser ?
Pour parvenir à ces malhonnêtes fins (on m'a toujours dit que copier c'était tricher) utilisons les "patterns" d'architecture.
Bref aperçu.
REST : un pattern d'architecture inter-applicative générique
Il est facile, en découvrant REST, de comprendre pourquoi un style d'architecture applicative peut influencer la stratégie de l'application, ses capacités d'ouverture et d'évolutions futures.
Le respect des principes REST dans les applications d'un SI permet de définir à l'avance les capacités futures du système à intégrer les services d'autres systèmes ou à fournir ses services à d'autres systèmes.
En d'autres termes, garantir que vous respectez un certain nombre de principes simples et intelligents, dont REST est un bon exemple, permet d'assurer l'évolutivité du système dans le cadre de ces principes (tautologie non ?), tout en étant sûr, puisqu'il en est ainsi dans REST, que vous ne fermez la porte à aucune technologie d'échange d'information.
REST n'est pas une solution en soit, mais un outil garantissant que vous ne faites pas entièrement fausse route.
A ne pas manquer, sur le même sujet :
- REST : http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
- protocole HTTP : http://www.w3.org/Protocols/rfc2616/rfc2616.html
- W3C : http://www.w3.org/TR/webarch/
- sur le site de JP. Figer : http://www.figer.com/Publications/REST.htm
MVC : un pattern d'architecture logicielle générique
Même si l'intérieur d'une application peut être conçu au style REST (bonne idée d'ailleurs), son design doit être vu de manière souvent plus précise. Ceci est d'autant plus vrai que l'application intégrera des données, des écrans et divers utilisateurs éventuellement simultanément.
La définition très précise de MVC (ou de MVC2) permet de concevoir l'application sans se poser la question du style d'architecture interne, du respect de tel ou tel pattern. Il ne reste plus au concepteur qu'à chercher le framework d'implémentation le plus adapté à l'application et au langage utilisé.
L'erreur classique du développeur qui consiste à "tout casser puisque le modèle n'était pas le bon" peut alors être évitée au moins en ce qui concerne les liaisons entre la visualisation, la présentation, la structuration et les modèles de données, l'internationalisation et éventuellement l'accès aux données persistantes.
A ne pas manquer, sur le même sujet :
- sorte de MVC pour les nuls (c'est vieux mais ça explique bien) : http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
- la vision sun de MVC : http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
Autres patterns...
Ce que je constate souvent c'est que l'application des patterns d'architecture se fait quel que soit le niveau (sorte de fractale, comme démontré dans [YCS]) : au niveau composant d'une librairie, au niveau application, au niveau liaisons inter-systèmes, au niveau application server, etc.
Un grand jeu de mon quotidien consiste à utiliser les Design Patterns [GOF] à tous les niveaux de l'architecture du SI, de la note de stratégie globale au détail d'un bout de code. Vous verrez, ça marche !
A votre tour, si ça vous chante, postez en commentaire de cet article les références vers vos meilleurs patterns.
A ne pas manquer, sur le sujet :
- Sun fait le lien entre des use cases et des patterns associés : http://java.sun.com/developer/technicalArticles/J2EE/despat/index.html
- l'architecture J2EE décrite, entre autre, au travers de patterns : http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/
Références ci-dessus :
[GOF] Design Patterns - E. Gamma, R. Helm, R. Johnson, J. Vlissides
[YCS] Urbanisation et BPM - Y. Caseau
