Discussion :

[soulhouf]

bonjour,
je vais bientôt commancer un gros projet d'un logiciel de vente en ligne (dans le cadre de mes études) qui sera fait en une équipe de 7 à 12 personnes.
Je me pose d'abord la question sur le choix des technologies pour la réalisation:
- SGBD: JDBC?
- Web: JSP?
- programmation distribuée: Java?
- Réseaux: TCP/IP, sockets?

je voudrai aussi savoir pour ce genre d'application quelle est la meilleure architecture (du moins la plus utilisée) à employer?
merci d'avance.

[dlemoing]

La question que je me pose avant toute chose : pourquoi distribuer ton application ?

Prenons chacune des couches en considération :
1- la persistance : pour cela tu peux effectivement utiliser JDBC mais je te conseillerais plutot d'utiliser un framework d'abstraction au dessus de JDBC (regarde Spring JDBC ou DBUtils par exemple). Tu peux également te tourner vers une solution de type ORM (Hibernate par exemple) si tu sens que ton appli peut bénéficier d'un Domain Model riche (dans le cas que tu cites, je partirais certainement sur ce type de solution)
2- un Domain Model qui représente tes objets métiers (Produit, Commande, Client, ...). Le Domain Model contient des données ET un comportement. Tes objets métiers ne doivent pas être vides de logique métier.
3- une couche de service dans laquelle tu feras appel à ta couche de persistance pour récupérer des objets métiers et travailler avec. Cette couche peut également contenir de la logique métier relative à des cas spécifiques.
4- une couche web avec un controleur qui travaille avec la couche service, récupére un Model (sous la forme d'objets métiers ou de DTO) et le passe à la Vue (JSP, Tapestry, ...). Pour cette partie, tu peux utiliser un framework web. Struts est le plus répendu et le plus "populaire". Si tu en veux un plus évolué (à mon gout), regarde Spring MVC.

Si tu tiens vraiment à distribuer ton appli, il faut que tu donnes plus de détails sur ton besoin : Pourquoi distribuer ? Type de clients (Java, .Net, ...) ?
Si tu veux toujours distribuer ton appli, tu peux très bien le faire sans descendre au niveau socket. Les premières solutions à ta disposition sont les services web et RMI. (Spring facilite le déploiement de services distribués de manière déclarative)

[soulhouf]

merci pour la réponse.
en faite la distribution ne vient pas d'un choix personnel mais c'est ce qui est demandé dans l'énoncé du projet...

[soulhouf]

dlemoing peux tu me détailler un peu plus les couches 2 et 3? et qu'est ce que tu veux dire par "logique metier"?

[mauvais_karma]

se sont les traitements ou des actions a effectuer:
ex: calculer une facturation, lister les produits d'une commande

dans la couche 2, la logique métier va intervenir sous forme de controle lors de la création de tes objets métiers (constructeur) ou sur les getters, ou de méthodes pour gérer les propriéés encapulée (ajouter/retirer un elt d'une collection par exemple)

et comme me l'a appris dlemoing, les services métiers sont des méthodes transactionelles

[kameleo10]

Bonjour,

A mon avis, adopter une architecture 3 tiers fera l'affaire.(J2EE ou .Net).

-La couche présentation : action et action form de Struts en J2EE par exemple.
-La couche Métier : l'implémentation de ton diagramme des classes, essaie d'appliquer aux design patterns objet ils sont intéressant pour la maintenabilité et la compréhension du code.
-La couche Persistence : couche d'accès aux données Hibernate par exemple ( équivalent en DotNet nHibernate pas très mur).

A mon avis utiliser les web services pour la communication entre les différents modules (web services standard et permet des communication entre systèmes hétérogènes malgré la lenteur).

[dlemoing]

se sont les traitements ou des actions a effectuer:
ex: calculer une facturation, lister les produits d'une commande

On peut résumer ca comme ca.

dans la couche 2, la logique métier va intervenir sous forme de controle lors de la création de tes objets métiers (constructeur) ou sur les getters, ou de méthodes pour gérer les propriéés encapulée (ajouter/retirer un elt d'une collection par exemple)

C'est vrai mais ce n'est pas tout. Effectivement quand tu vas vouloir ajouter une ligne de commande à une collection contenue dans ton objet Commande, tu vas vouloir valider qu'on ne te passe pas un objet null, auquel cas tu peux renvoyer une IllegalArgumentException.
Tu as certainement déjà manipulé des exemples avec des comptes bancaires. Quand tu fais un retrait tu ne fais pas ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Compte {
    private int solde;
...
    public void retrait(int montant) {
        solde = solde - montant;
    }
...
}
...
Compte compte = ...
if (compte.getSolde() >= montant);
    compte.retrait(montant);
else
    throw new BusinessException("...");

Mettre du métier dans ton domain model consisterais à faire ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Compte {
    private int solde;
...
    public void retrait(int montant) throws BusinessException{
        if (this.getSolde() >= montant);
            this.setSolde(solde - montant);
        else
            throw new BusinessException("...");
    }
...
}
...
Compte compte = ...
compte.retrait(montant);

Quand tu voudras calculer le prix d'une commande, comment vas tu faire ? Vas tu charger toutes les lignes de commande et les itérer explicitement à chaque fois que tu en auras besoin ou utiliseras tu ton objet commande qui se chargera de le faire pour toi (une méthode calculerPrixCommande par exemple) ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class Commande {
    private Collection lignesCde;
...
    public int calculerPrixCommande() {
        int prix = 0;
        Iterator it = lignesCde.iterator();
        while (it.hasNext())
        {
            LigneCommande lc = (LigneCommande)it.next();
            prix += lc.calculerPrixLigneCde();
        }
        return prix;
    }
...
}
...
public class LigneCommande {
    private Produit produit;
    private int qte;
...
    public int calculerPrixLigneCde() {
        return produit.getPrixUnitaire() * qte;
    }
...
Commande cde = ...,
int prixCde = cde.calculerPrixCommande();
}

La remarque que je faisais avait juste pour but de te faire prendre conscience qu'un Domain Model qui ne serait composé que d'objets simples sans comportement (uniquement des getters/setters) n'est pas forcément une bonne chose dans la mesure où ca t'éloigne des bonnes pratiques objets (objet = données et comportement). On appelle ca un AnemicDomainModel

et comme me l'a appris dlemoing, les services métiers sont des méthodes transactionelles

Plus exactement, si tu as besoin de démarquer des transactions, c'est généralement au niveau de l'interface de la couche de service qu'il faut le faire.

Peux tu préciser à quel niveau doit intervenir la distribution dans ton appli ? S'il s'agit de la rendre extensible en utilisant des services web ca devrait pas poser trop de problèmes...mais si tu veux en faire un choix central d'architecture je te souhaite pas de tomber sur quelqu'un comme moi en soutenance (ou pour ton rapport).

Si tu veux des infos sur comment bien architecturer tes applis, je te conseille quelques lectures :
http://www.martinfowler.com/books.html#eaa
http://www.springframework.com/books/ (les 2 premiers et le 4eme)

[soulhouf]

Peux tu préciser à quel niveau doit intervenir la distribution dans ton appli ? S'il s'agit de la rendre extensible en utilisant des services web ca devrait pas poser trop de problèmes...

oui c'est effectivement à ce niveau là.
en tout cas merci beaucoup pour ton aide