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

Langage Java Discussion :

Couche business, couche dao


Sujet :

Langage Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    115
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2003
    Messages : 115
    Par défaut Couche business, couche dao
    Bonjour tout le monde,

    je travaille actuellement sur un projet interne de la boîte, où l'on gère des employés, et je me pose des question "architecturale" au niveau du rôle concret de la couche business et DAO au sein d'une application.

    Exemple : Récupérer toutes les personnes dont le prénom commence par "O"
    Moi j'aurai tendance à laisser travailler le sgbd pour nous et faire
    une méthode dans la couche service et une méthode dans la couche DAO
    par exemple:
    EmployeeServices.java
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    public List getEmployeeByName(String name){
       DaoEmployee dao = new EmployeeDao(); 
       return dao.getEmployeesByName(name);
    }
    et donc forcement j'ai du rajouter une méthode dans ma couche DAO afin d'attenindre mon objectif

    2 eme idée : Se dire que le Dao contient deja la plupart des méthodes classqiues et qu'alors j'effectue un tri dans ma couche business moi même avec boucle for et tout le tralalala...


    Et vous que feriez-vous ?


    Merci de vos réponses sur ce petit sujet qui crée des divergences .
    Bien à vous,
    omlip

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 94
    Par défaut
    Pour moi tout cela dépend vraiment du contexte de l'application, sans connaitre votre cas particulier voici mon humble avis :

    Si l'appli fonctionne avec un état et que tu as déja la liste de personnes loadée dans une liste ou un set, il vaut mieux réutiliser cette liste en faisant une restriction métier, cela évite de multiplier les requêtes SQL ( surtout si le serveur de données n'est pas en localhost )

    Par contre si tu fonctionnes sans état et que chaque appel génère une requete dans ce cas autant mettre la restriction dans la requete SQL.

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    115
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2003
    Messages : 115
    Par défaut
    Notre situation est une application Web,

    la liste n'est pas retenue en mémoire ou quoi que ce soit, on remplit un formulaire avec 1 textfield, puis on passe par l'Action Struts, puis dans le services, puis la on récupère nos données...


    Donc dans ce cas tu penserais à laisser le sgbd s'occuper de cette logique ???
    PS : de toute façon on doit faire une requete SQL derrière


    Merci
    Omlip

Discussions similaires

  1. Réponses: 0
    Dernier message: 20/04/2011, 16h07
  2. Réponses: 24
    Dernier message: 18/12/2009, 15h25
  3. DC avec couche service et dao
    Par jaljal dans le forum Diagrammes de Classes
    Réponses: 10
    Dernier message: 29/09/2009, 17h25
  4. Réponses: 5
    Dernier message: 03/11/2008, 12h29
  5. LA couche business
    Par topolino dans le forum ASP.NET
    Réponses: 2
    Dernier message: 16/10/2008, 13h03

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