[MVC] Bien séparer les couches : validité du pattern ?

Salut à tous,

Je débute en programmation d'applications web et je me suis donc intéressé de près aux design patterns utilisés pour ce genre d'application. Comme une application peut être divisée en trois "pôles" : Présentation, Données et Logique Applicative, le design pattern classique est une architecture 3 tiers.
Et, si j'ai bien tout compris, l'objectif c'est de séparer au maximum ces 3 couches afin d'augmenter maintenabilité et évolutivité (par exemple avec le framework Spring en J2EE). Jusque là je pense que je suis. (arrêtez moi si je dis des bêtises quand même)

Le problème c'est que dans beaucoup d'exemples et de tutoriaux que j'ai rencontré, à ces 3 couches qui sont censées être entièrement distinctes on ajoute un 4ème composant, en général appelé "modèle". On obtient donc l'architecture suivante :
http://www.onjava.com/onjava/2004/04...ics/wiring.gif
J'ai trouvé cette image sur ce site qui explique comment concevoir les applis web en Java.

Concrètement ce "modèle de données" ne contient que des "objets métiers", des classes sans aucune logique applicative servant uniquement à stocker les données de l'application. Le problème c'est que ces classes sont partagées par TOUTES les couches de l'application.

Pour moi c'est une grosse entorse à la séparation des différentes couches. 8O
J'aurais plutôt vu une architecture où chaque couche possèderait son propre modèle de données et les SEULES interactions possibles entre les couches doit se faire à l'aide d'interfaces.

Je voudrais donc connaître l'avis d'autres personnes. Quel sera l'impact de ce genre d'architecture sur la maintenabilité de l'application et est-ce que c'est vraiment un modèle à suivre ou juste un détournement des architectures 3-tiers ?

Le truc, c'est que les couches sont amenées à communiquer, sinon l'application ne sert à rien. Pour ce faire, il y a forcément des objets qui vont transiter entre les différentes couches.
Il est logique que ces objets soient connus de chaque couche si on veut être en mesure de les passer, d'où l'utilité de cette couche transversale.

Pour prendre l'exemple d'une opération simple, tu souhaites récupérer un utilisateur par son nom pour l'afficher dans une fenêtre, et ensuite le modifier et updater dans la base de données.

Pour commencer, dans la couche transversale, tu crées une classe UserEntity

Code:

---

1 2 3 4 5 6 7

class UserEntity { int id; string nom; string password; .... }

---

Dans la BL tu crées une classe ou des méthodes statiques de manipulation des users style

Code:

---

1 2 3 4

UserEntity GetUserByID( int idUser) //pour récupérer un utilisateur par son ID SaveUser( UserEntity user) //dans laquelle on teste la validité avant de procéder a l'enregistrement ....

---

Ces méthodes sont appelées par l'UI, soit directement, soit par le biais d'une interface.
La couche transversale te permet de stocker les définitions des objets qui passent entre les deux couches, en l'occurrence, le UserEntity.

Pourquoi penses-tu que c'est un problème? As-tu un exemple?

Je ne pense pas forcément que ce soit un problème, je me posais juste la question.

C'est vrai que, quand on y réfléchit, tant que ces objets ne possèdent pas de logique applicative et ne sont utilisés que pour définir un modèle de données, on conserve la séparation des couches.

Le seul problème que je vois c'est au niveau de l'évolutivité, si on change le modèle de données, on est obligé de revoir et retester chacune des couches. Mais toucher au modèle de données ça revient à toucher à la conception profonde de l'application donc j'imagine que même si chaque couche avait son modèle de données propre, on devrait revoir et retester l'application de fond en comble quand même.

Bon ben ça m'a fait du bien d'en parler. Je pense que je me suis convaincu moi-même que ce design pattern était "bon". :mouarf:
Après c'est toujours le contexte qui permet de choisir.

Quand tu parles de modification du modèle de données, tu parles de modification de la base de donnée?

Euh... oui et non.

Je pensais pas spécialement à la base de données mais oui, j'imagine que si les objets échangés entre les couches changent alors les tables de la base de donnée changent aussi.

Dans mes deux posts précédents "modèle de données" désigne cette couche transversale qui me posait problème au niveau de l'architecture (sur le schéma elle est appelée Domain Model Business Objects).