IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MVC Discussion :

relation couche métier/couche données


Sujet :

MVC

  1. #1
    Membre averti Avatar de mapmip
    Profil pro
    ulla
    Inscrit en
    Juillet 2006
    Messages
    1 314
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : ulla

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 314
    Points : 346
    Points
    346
    Par défaut relation couche métier/couche données
    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

  2. #2
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    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.

    Je souhaite savoir s'il faut relier directement la couche métier à la couche données
    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.

    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

Discussions similaires

  1. Architecture couche métier <-> couche présentation
    Par bozo614 dans le forum Visual C++
    Réponses: 7
    Dernier message: 22/11/2007, 18h11
  2. Relation entre EJB, couche métiers, JSP et servlet
    Par infinity21 dans le forum Servlets/JSP
    Réponses: 13
    Dernier message: 06/03/2007, 00h50
  3. Organisation Couche métier
    Par tatemilio2 dans le forum Hibernate
    Réponses: 1
    Dernier message: 08/09/2006, 15h29
  4. [Architecture] Couche accès aux données
    Par tatemilio2 dans le forum Hibernate
    Réponses: 3
    Dernier message: 12/06/2006, 11h23
  5. Couche métier = forcement EJB ?
    Par jothi35 dans le forum Java EE
    Réponses: 9
    Dernier message: 14/09/2004, 17h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo