Discussion :

[DomIII]

Bonjour,

Je suis sur le point de prendre un nouveau projet, je dois d'abord rédiger une proposition de solution, j'aurais besoin d'un conseil.

En outre, je me dois de construire une web application en Struts 1.3 laquelle doit se connecter à une base MySQL 5.

Cette base contient un environ 1Go de données, elle doit gérer au plus 30 connexions simultanées, filtrées et régulées par des load balancers en amont du serveur web (tomcat/apache). L'application web répond à l'architecture classique MVC, avec les 3 couches sur le contrôleur : présentation / accès données / métier. J'ai carte blanche pour la gestion des requêtes. Les plus gros flux de données (au pire 30 méga-octets) se font de nuit pour des requêtes de statistiques, rien de bien méchant.

Cette connexion à une base de données est une étape complètement nouvelle pour moi, puisque souvent on me donnait les moyens de faire des requêtes en base via des web services que je n'ai jamais développés.

Ainsi, je voudrais avoir un conseil : que me conseilleriez-vous pour connecter la web application à MySQL ?

La priorité est la performance, il m'est demandé quelque chose de fiable. Je dois rendre ma copie dans quelques jours... Je suis déjà sous pression.

Merci par avance de vos conseils éclairés.

[verbose]

Je ne suis pas un grand spécialiste des bases de données, mais je peux te faire part de mon expérience.

Si la priorité absolue est la performance, les procédures stockées sont ce qu'il y a de plus efficace car elles sont compilées. Dans ce cas, il est indispensable de recourir à une architecture comprenant des DAO (Data Access Object) pour l'accès aux données.

Maintenant, les ORM (Hibernate, iBatis, etc..) offrent des performances souvent suffisantes dans la plupart des cas. Elles offrent un gain de productivité, à condition de bien connaître le framework et d'avoir un schéma de base de données relativement simple. Il y a beaucoup de documentation pour Hibernate et les forums sont actifs.

[DomIII]

Je ne suis pas un grand spécialiste des bases de données, mais je peux te faire part de mon expérience.

Si la priorité absolue est la performance, les procédures stockées sont ce qu'il y a de plus efficace car elles sont compilées. Dans ce cas, il est indispensable de recourir à une architecture comprenant des DAO (Data Access Object) pour l'accès aux données.

Maintenant, les ORM (Hibernate, iBatis, etc..) offrent des performances souvent suffisantes dans la plupart des cas. Elles offrent un gain de productivité, à condition de bien connaître le framework et d'avoir un schéma de base de données relativement simple. Il y a beaucoup de documentation pour Hibernate et les forums sont actifs.

Bonjour,

Merci pour ta réponse. Bien que je fasse du Java depuis environ 6 ans, quasiment des web-applications, il fallait bien un jour ou l'autre que je me plonge dans la couche métier. L'heure a donc sonné.

Je suis cependant totalement étranger aux DAO, je vais donc faire des recherches sur le Net. Cependant, est-ce une architecture complexe ou facile à configurer, exploiter et maintenir ? En outre, en bon chef de projet technique, je dois définir les délais et les ressources nécessaires - en d'autres termes, répondre à la délicate question : combien je facture - ce qui signifie que je n'ai pas du tout intérêt à me planter, devant tout justifier.

A priori, tu sembles bien connaître ?

[verbose]

J'ai assez peu d'expérience, donc je ne peux pas te donner d'indication concernant la facturation.

Pour les DAO, c'est très simple. Le principe consiste à circonscrire le code SQL à quelques classes appelées DAO. Dans la couche métier, on ne manipule que des beans.

Les DAO ressemblent à quelque chose comme ça :

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
 
public class Client {
    private String nom, prenom, ....
}
 
public class ClientDAO {
    public List<Client> getClient(String nom) {
        //requete de selection
    }
 
    public void nouveau(Client client) {
        //requete d'insertion
    }
 
    [...]
}

Le DAO fait ainsi la jonction entre la couche persistence et la couche métier.

[hasalex]

Tu gagneras en productivité avec Hibernate ou JPA. Les seuls risques sont pour les perfs sur des grosses requêtes un peu complexes, auquel cas, tu peux passer directement des requêtes SQL.
En réalité, il faut éviter Hibernate ou JPA dans le seul cas où tu as une base de données avec beaucoup des clés primaires composites, typées métier.

[OButterlin]

Il ne faut pas perdre de vue qu'il doit rendre sa copie dans quelques jours...

La solution la plus facile à appréhender est certainement JDBC (avec ou sans procédures stockées).
Les performances sont très bonnes.

Hibernate (ou autre ORM) est une bonne manière de persister en base de données, le problème, c'est qu'il faut un temps certain d'apprentissage.

Le concept de DAO peut être retenu quelque soit la solution envisagée.
Son principe de base est de centraliser dans un objet spécifique toutes les opérations sur une "entité" (client, facture, article, ...), ce qui permettra d'utiliser les fonctions n'importe où.