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ù.

[DomIII]

Bonjour,

Et merci pour vos conseils.

Pour résumer, mieux vaudrait que je m'appuie sur JDBC. En outre, je rends ma proposition de solution vendredi de cette semaine (déjà !), je prépare une présentation avec transparents. Je risque d'être confronté à des questions techniques, à savoir pourquoi avoir choisi JDBC et MySQL.

Concernant MySQL, je sais argumenter : libre, reconnu et adapté pour une base de petite taille finalement avec des flux peu volumineux (quelques méga-octets par nuit).

Ensuite, je peux expliquer le pourquoi du Struts/Java, ayant plusieurs années d'expérience et de pratique.

Lorsqu'il s'agira de JDBC, je pourrai toujours dire que ce framework (s'il l'est bien) performant et suffisant. D'où le fait que je sois là pour en parler et en discuter. L'idéal serait pour moi de donner quelques chiffres...

Les développements commenceront au plus tôt à la fin mars, une fois que la solution aura été validée s'il est acceptée. Sans me mettre la pression et sans dramatiser l'enjeu, je joue mon image... et une promotion de directeur de projets dans ma boîte

Imaginez alors que je produise rapidement une petite maquette avec une base composée d'une simple table. Je pense que je marquerai alors de bons points.

Ainsi, je souhaite profiter de ce projet pour me mettre aux base de données.

Merci par avance de vos suggestions/questions, sachant que je suis ouvert à toute question.

[OButterlin]

Pour ce qui est des performances, il est certain qu'avec JDBC tu auras ce qui ce fait de plus performant, surtout si derrière, tu attaques des procédures stockées.
Le seul "problème" pourrait venir d'une conception devant s'adapter à plusieurs base de données, mais ce n'est pas ton cas, donc vas-y, fonce

Sinon, contrairement à ce que tu sous-entends, JDBC n'est pas un framework, c'est une API (ça pourrait faire désordre dans une discussion avec un connaisseur, si déjà tu joues une bonne place)
Pour le reste, quel genre de logiciel veux-tu développer ?

[DomIII]

Pour ce qui est des performances, il est certain qu'avec JDBC tu auras ce qui ce fait de plus performant, surtout si derrière, tu attaques des procédures stockées.
Le seul "problème" pourrait venir d'une conception devant s'adapter à plusieurs base de données, mais ce n'est pas ton cas, donc vas-y, fonce

Sinon, contrairement à ce que tu sous-entends, JDBC n'est pas un framework, c'est une API (ça pourrait faire désordre dans une discussion avec un connaisseur, si déjà tu joues une bonne place)
Pour le reste, quel genre de logiciel veux-tu développer ?

Bonjour,

Et encore merci. Effectivement, JDBC est une API et non un Framework, un collègue m'avait d'ailleurs corrigé avant de rendre mon document.

L'application ciblée est un portail client pour suivre des commandes de services et de produits d'une société que j'appellerai ici XYZ pour préserver le secret. XYZ a émis le souhait d'avoir deux applications distinctes pour les commandes et le suivi des commandes. Ces deux sites ont chacun leurs bases de données. Quand un client fait un achat sur le site marchand, les informations enregistrées sont stockées sur le site marchand, puis transférées au plus tard 4 heures après sur le site de suivi. Chaque nuit, des scripts sont lancés pour calculer des statistiques diverses sur chacun des sites, ils s'échangent d'ailleurs des données.

Côté présentation, j'ai présenté une appli-web en Struts 1.3.8, j'ai acquis une certaine expérience sur ce framework.

Grâce à Developpez.com site, j'ai pu réaliser une maquette simpliste et ai pu montrer quelque chose d'assez simple qui semble avoir convaincu la société XYZ. Pour le JDBC, je me suis contenté de la classe Statement, mais il y aurait des moyens encore plus performants, ce que je n'ai pu voir pour le moment faute de temps. Si jamais il y avait des tutoriaux à ce sujet, je suis preneur De même, concernant les scripts à lancer chaque nuit, si JDBC permettait ce genre de batches, je suis preneur de toute information.

Merci encore à vous tous. Bien entendu, je reste ouvert à toute question supplémentaire.

Cordialement

[OButterlin]

Moi, je n'ai absolument rien contre le choix struts 1.3.8, je l'utilise également, très performant, simple à faire évoluer, et couplé à struts-layout, ça devient vraiment intéressant...

Pour JDBC, le seul bémol serait l'usage de Statement, il serait préférable d'utiliser PreparedStatement, il n'y a pas de risque d'injection ni de problème de type de données... bref, que des avantages.
Pour l'usage, c'est très proche de Statement...

Pour les batchs, ce n'est pas JDBC qui te permettra de paramétrer des exécutions planifiées, tu devrais regarder du côté de Quartz, c'est très bien fait et très simple à mettre en œuvre.

[DomIII]

Moi, je n'ai absolument rien contre le choix struts 1.3.8, je l'utilise également, très performant, simple à faire évoluer, et couplé à struts-layout, ça devient vraiment intéressant...

Pour JDBC, le seul bémol serait l'usage de Statement, il serait préférable d'utiliser PreparedStatement, il n'y a pas de risque d'injection ni de problème de type de données... bref, que des avantages.
Pour l'usage, c'est très proche de Statement...

Pour les batchs, ce n'est pas JDBC qui te permettra de paramétrer des exécutions planifiées, tu devrais regarder du côté de Quartz, c'est très bien fait et très simple à mettre en œuvre.

Bonjour,

Très bonne nouvelle : ma solution est validée ! J'ai donc le feu vert pour lancer le projet, le temps de régler quelques petits détails, et tout se met en route début avril.

Nouvelle question, mon cher (ma chère ?) OButterlin, je vais donc regarder de plus près les PreparedStatement. Si jamais il y a des tutoriaux intéressants, je suis preneur

Encore merci aux réponses qui m'ont été données, je vous associe à ce premier succès, maintenant le plus dur commence : je dois livrer une première version vers le 15 juin.

[OButterlin]

...
Nouvelle question, mon cher (ma chère ?) OButterlin, ...

En l'occurrence, "mon", désolé

Pour le PreparedStatement, tu peux regarder ceci.
Le plus "gros" problème avec JDBC, c'est l'acquisition d'une connexion et sa libération (autant dire, rien...)
Là encore, tu as le choix. Tu peux utiliser une source de données qui sera paramétrée sur le serveur (bonne externalisation) ou alors créer une petite classe utilitaire avec 2 méthodes static pour l'acquisition/libération.
Le but étant de toujours libérer une connexion à la fin d'un traitement.

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
28
public ... maMethode(...)
{
   Connection connection = null;
   PreparedStatement pstmt = null;
   ResultSet rs = null;
   
   try
   {
      connection = ...
      pstmt = connection.prepareStatement("...");
      rs = pstmt.executeQuery();
      while (rs.next())
      {
         ...
      }
   }
   catch (Exception e)
   {
   }
   finally
   {
      if (rs != null) try { rs.close(); } catch (Exception e) {...}
      if (pstmt != null) try { pstmt.close(); } catch (Exception e) {...}
      if (connection != null) try { connection.close(); } catch (Exception e) {...}
   }
}
lignes vertes optionnelles, en fermant la connexion, on ferme tout...

[DomIII]

Merci beaucoup mon cher OButterlin !

J'y vois de plus en plus clair, je vais donc profiter de ces quelques jours avant le début des opérations pour m'exercer au PreparedStatement.

Ce site est vraiment une mine d'or !

[DomIII]

Bonjour,

Les développements commenceront dans quelques jours, j'ai effectivement pu faire des tests, le JDBC répond parfaitement aux attentes. Mieux encore, un architecte de mon client XYZ a préconisé MySQL et approuve le choix de JDBC.

Maintenant, y'a qu'à !

[DomIII]

Et voilà, c'est fait ! La première version a été livrée dans les temps, au début du mois, la mise en production sera opérée dans la nuit de mercredi à jeudi. La période de tests est positive, il ne reste plus qu'à surveiller la montée en charge de l'application dans les prochains jours.

Prochaine étape : se mettre à Hibernate, je suis en train de l'étudier. Je vois que les choses seront nettement plus longues, mais après tout, il faut bien se lancer des défis !