Version imprimable
Bonjur,
il est recommandé de créer une couche controleur entre la couche presentation et la couche métier. Il est conseillé aussi que la couche présentation ne puisse pas accéder à la couche données.
Je souhaite savoir s'il faut relier directement la couche métier à la couche données ou créer un couche intermediaire ou utiliser la couche controleur pour lier couche métier et couche données.
Merci d'avance
On ne peut pas vraiment raisonner en termes de "il faut", "on doit"... Il y a autant de variantes de MVC que d'applications.
Certains appellent la couche d'accès aux données directement depuis le Contrôleur (via des DAO, des Repository...) D'autres invoquent la nécessité de réutilisabilité et introduisent une couche de Service métier entre Contrôleur et DAO qui va encapsuler ces appels.
Attention, si par couche métier tu entends les objets métier eux-mêmes, c'est certainement une mauvaise idée d'y inclure de la logique de persistance et d'accès aux données. Pour respecter le Single Responsibility Principle, on préfère toujours déléguer la responsabilité de persister/requêter des données à des objets séparés comme des DAO ou des Repository. Si on prend la couche métier pure c'est à dire seulement les objets métier, elle n'a donc pas de dépendance vers la couche d'accès aux données.Citation:
Je souhaite savoir s'il faut relier directement la couche métier à la couche données
Il y a ambiguité sur les termes car dans "couche métier" certains englobent à la fois les entités métier (business objects) et les services qui peuvent graviter autour. D'autres parlent de "couche métier" et "couche services" distinctes. Tout ça se mélange aussi avec la notion de Model de MVC qui recoupe plus ou moins de choses.
Bref, pas de règle absolue en la matière, du moment qu'on sépare bien ce qui relève d'activités différentes (métier/afficher/persister...) pour avoir des objets modulaires, réutilisables et qui n'ont pas 36 raisons de changer et de casser.
Cf http://stackoverflow.com/questions/6...ntroller-layer