[Language]comment faire une application à 3 couches en java

Version imprimable

23/11/2005, 10h23
geo-2

[Language]comment faire une application à 3 couches en java

Bon voila je voudrais implementer une application à 3 couches :roll: (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 :roll:. Si je ne suis pas sur la bonne route je compte sur vous pour me guider :idea: .

[ Modéré par Bulbo ]
Ajout d'un tag dans le titre
:arrow: Les Règles du Forum
23/11/2005, 10h41
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.
23/11/2005, 17h27
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 ! :D
23/11/2005, 22h19
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).
23/11/2005, 22h58
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

Voila un exemple très simple :

Code:

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

Code:

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

Code:

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:

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

Code:

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:

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);
        ...
    }
}