Discussion :

[geo-2]

Bon voila je voudrais implementer une application à 3 couches (couche présentation, couche metier et couche d'accès aux données) en java afin de comprendre et d'estimer moi même les avantages d'une pareil approche car je suis un newbie. Le problème c'est que dans la littérature les couches communiquent par le biais d'interfaces : , et là franchement je me perds.

Actuellement j'ai 3 packages qui sont :
com.test.ui : pour les classes de présentions
com.test.core : pour les classes métiers
com.test.data : pour les classes d'accès aux données

Je pensais faire un import du package com.test.core dans les classes de présentations et un import du package com.test.data dans les classes de métier.

Et au finish je ne vois pas l'intérets des interfaces (ni même comment les mettre en oeuvre), ou bien c'est moi qui ne comprend pas ce qu'est une interface . Si je ne suis pas sur la bonne route je compte sur vous pour me guider .

[ Modéré par Bulbo ]
Ajout d'un tag dans le titre
Les Règles du Forum

[bourbaki2003]

Les interfaces Java permettent de spécifier un comportement tout en ne se souciant pas de l'implémentation. Par exemple, pour ton accés à tes donnèes tu définis une interface qui décrit l'ensemble des opérations pouvant être effectuées sur les données. Ton controleur ne doit connaitre que cette interface et ne doit se soucier que de celle-ci. Enfin du cote des données tu crees une classe qui implémente ton interface.

Je ne sais pas si j'ai été tres clair.

[Regis.C]

En tout cas bravo pour l'effort du choix d'architecture à 3 couches...
Cela fait plaisir de voir que des dev' pensent à ceux qui sont susceptible de passer derrière pour maintenir ou ajouter des fonctionnalités !

[bouye]

Mais de la a faire 3 packages separes... Faut voir celon l'usage.
L'ennui c'est que de cette maniere tu vas declarer tout un tas de trucs publiques sur chacun des 3 niveaux et qui sont donc succeptibles d'etre utilises/hackes (au sens bidouillage) de l'exterieur par qqun d'autre. Egalement cette maniere est plus propre mais a tendance a complexifier les interactions entre les niveaux (toujours a cause du fait qu'on ne pas passer que par des methodes publiques ou par de l'heritage).

Moi je separe bien les couches du programme, mais en general je met tout dans le meme package (sauf si il y a vraiment besoin de reutiliser) en package protected (ne pas mettre de modificateur public/protected/private devant le mot-cle class) et je m'arrange dans la maniere de nommer mes classes pour que les fichiers/classes des 3 couches ne se melangent pas.

Apres peut-etre veux-tu reellement que qqun fasse un vue differente de ton modele ou re-utilise ailleurs tes methodes d'acces aux donnees (et dans ce cas t'as tout bon). Mais alors pense/reflechit bien tes interfaces et methodes/access publiques dans ce cas (toujours en pensant reutilisabilite).

[dlemoing]

Pour ma part, voila mon organisation en package :

com.entreprise.appli.domain: objets métiers (domain model)
com.entreprise.appli.dao : couche d'accès aux données
com.entreprise.appli.service : couche de service qui appelle la couche dao pour récupérer des objets métiers utilisés pour la logique métier
com.entreprise.appli.web : j'y place le code relatif à mes controleurs
com.entreprise.appli.validator : implémentations d'une interface Validator
com.entreprise.appli.util : outils utilisés un peu partout
com.entreprise.appli.schedule : batchs
com.entreprise.appli.dto : si je suis amené à faire de la distribution

Souvent, je mets les interfaces à la racine et les implémentations dans des sous-packages spécifiques (jdbc ou hibernate pour les dao, impl la plupart du temps)

Les principales dépendances à connaitre :
- les objets métiers n'ont pas de dépendances avec les autres couches (util à la limite)
- les dao ont une dépendance vers les objets métiers (et la technologie de persistance sous-jacente au niveau de l'implémentation)
- les services connaissent les dao et les objets métiers
- les controleurs (partie web) connaissent juste les services et les objets métiers retournés

[dlemoing]

Voila un exemple très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class Commande {
    private long idCommande;
    private List lignesCde;
    ...
    public BigDecimal calculerPrixCommande() {
        ...
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public interface CommandeDAO {
    public List chargerCommandes();
    public Commande chargerCommandeById(long id);
...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class CommandeDAOImpl {
    public List chargerCommandes() {
    //chargement de toutes les commandes
    }
    public Commande chargerCommandeById(long id) {
    //chargement d'une commande en base et creation d'un objet Commande
    }
...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface CommandeService {
    public BigDecimal calculPrixCommande(long id);
...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class CommandeServiceImpl {
    private CommandeDAO commandeDAO;
 
    public BigDecimal calculPrixCommande(long id){
        Commande cde = commandeDAO.chargerCommandeById(id);
        return cde.calculerPrixCommande();
    }
...
}

controleur web :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class Controleur {
    private CommandeService service;
 
    public void perform(...) {
        long id = ...;
        BigDecimal prix = service.calculPrixCommande(id);
        ...
    }
}