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