Voyons un peu ce que certains framworks, que l'on peut qualifier de standard apportent à l'architecture N-Tiers.
THE framework, limite on ne peut plus s'en passer, il permet beaucoup de choses et surtout d'intégrer et configurer d'autres frameworks... bref c'est souvent la pierre angulaire du projet. Mais c'est tout simplement un framework IoC ou d'injection de dépendances. Il permet de mieux découpler les couches. Ainsi on code avec les interfaces et c'est Spring qui se chargera (par la configuration ou les annotations) d'injecter l'implémentation. Point de factory, de singleton à implémenter soi-même.
Il n'a pas d'impact sur le nombre de couches mais il apporte une méthode élégante pour réaliser le couplage faible (par interface) entre les couches.
JEE permet aussi de réaliser l'injection avec une facilité équivalente (annotations)
Coté .NET on trouve des frameworks équivalents mais peut-être pas aussi bien aboutis avec le ServiceLocator et/ou les frameworks Unity, SimpleIOC et Castle. Encore que
springframework.net semble palier à cela (promis prochain projet .net je le tente).
Aujourd'hui les ORMs sont matures et permettent de masquer l'accès aux bases de données. Là on voit deux méthodes : ceux qui tiennent à la couche de DAO traditionnelle, cette dernière est alors triviale pour tout ce qui est CRUD, mais elle permettra d'isoler le code spécifique pour réaliser des fonctionnalités non prises en charge par l'ORM (rares).
Une approche plus moderne est de faire disparaître cette couche, de s'appuyer directement sur l'ORM depuis la couche métier, et de faire porter le CRUD et les requêtes complexes par le modèle (les classes d'entités de persistance) lui même.
Ainsi si on a une utilisation standard de la persistance dans une base de données relationnelle ou non (certaines base NoSql supportent les standard JPA ou JDO), l'ORM permet de remplacer la couche de DAO et simplifie grandement la structure du projet. C'est ce que l'on voit mis en oeuvre avec les approche de type Rails de Grails par exemple.
Les web service sont générés par des framework tiers. De même que les ORM, on peut piloter la mise en forme du message du service par des annotations sur le modèle d'échange (qui peut être ou non celui de persistance). Ce qui réduit l'implémentation d'un service à son strict minimum, seule l'interface est rédigée, l'implémentation est un passe plat qui appelle la couche métier.
L'Aspect Oriented Programing est un paradigme de programmation qui se place au dessus de la programmation orientée objet.
La mise en oeuvre de l'AOP dans une architecture en couche permet d'implémenter des responsabilités transverses aux couches d'architecture ou spécifique à une couche, une classe, une méthode. Bref cette technique est très flexible et elle permet élégamment de mettre en place une fonctionnalité transverse de type :
- réalisation des logs
- sécurité
- gestion de caches
Cela permet de mettre un peu d'huile entre les différentes couche de l'application. En respectant un couplage faible par l'utilisation d'interface, grâce à ces dernières, l'AOP se met en place avec un moindre coût.
Les frameworks MVC our MVVM et autre permettent de réaliser la couche de présentation, mais même si eux même ont un découpage Modèle Vue Contrôleur, ou Modèle Vue VueModel, bref un découpage en 3 catégories il ne faut pas prendre ces dernières comme des couches d'architecture applicative. Peut-être qu'avec un peu de chance le Modèle du MVC correspondra au domaine de l'application. C'est typiquement ce qui arrive dans les architecture Rails ou par convention le domaine est afficher directement, le contrôleur semble être la couche métier et la vue la présentation... mais c'est du Rails. Dans les applications qui ont un peu d'historique et de complexité ce n'est pas le cas, le modèle du MVC est différent du modèle métier de l'application et appartient intégralement à la couche de présentation.
Cet outil permet de recopier récursivement une grappe d'objet dans une autre grappe par réflexion et en utilisant un fichier de mapping, c'est un outil
TRÈS PUISSANT... trop ? J'en parle car je l'ai vu mis en dans le but de découpler les couches logiques d'une application. OK ils disent que c'est un
usage possible. Cela ne me semble pas une bonne pratique :
- surcoût en terme de mémoire et CPU
- maintenance complexe du code : une propriété doit être ajoutée à plusieurs classes et si son nom change un mapping spécifique dozer doit-être mis en place et testé.
Bref il ne faut mettre un tel outil que s'il apporte une valeur ajoutée importante sur un projet et dans le cadre d'une architecture en couche logique, je ne vois pas sa valeur ajoutée. Sauf dans des cas particuliers, avec un historique lourd... et alors c'est le dernier espoir...
