Choix stratégique en Java/JEE

Bonjour,

Je dois réaliser une étude pour une application web en Java/JEE, une refonte d'une hydre qui n'est plus maintenable. Pour ne pas reproduire les mêmes erreurs je me pose plusieurs questions. Il est bon de savoir que la priorité est l'affichage rapide d'un grand nombre d'informations.

Pour cela je me demandais:

-Est ce plus rapide de stocker des procédures dans ma base MySQL puis faire appel à elles avec JDBC dans une servlet OU d'utiliser une couche de persistance?

-Est ce intéressant de faire des web-services plutôt que des servlets?

Voila j’espère que ces deux questions ne sont pas trop bêtes, mais j'attache de l'importance à bien faire ma première étude et surtout à comprendre ce que je fais :)

Je vous remercie d'avance pour vos réponses.
Bonne fête de fin d'année!

Bien cordialement

Un Electron Libre

Les procédures stockées donnent le meilleur résultat en terme de vitesse. On récupère ensuite les données avec JDBC.
Il y a plusieurs avantages attendus :
on peut travailler la procédure pour l'optimiser (choix des index, utilisation de table temporaire etc.) sans que java ne soit concerné
on "masque" à java la façon de produire les données ; ce qui veut dire que si on a besoin de changer la structure de la base, on modifie la procédure stockée sans modifier l'application java

Merci pour votre réponse.

C'était ma première impression, mais comme je vois énormément de personnes qui mettent leur sql dans du java ou qui passe par de l'abstraction, je me posais des questions. Donc c'est parti pour les procédures ;)

Du coup il me reste ce souci de servlet/webservice et je passerais en résolu :ccool:

Plop,

Tout comme l'a dit Népomucène, il y a des avantages à utiliser des procédures stockées. Néanmoins l'inconvénient majeur, selon moi, est la portabilité. Si tu es amené à changer de type de bases de données, tu devras tout refaire ...

Citation:

---

Est ce plus rapide de stocker des procédures dans ma base MySQL puis faire appel à elles avec JDBC dans une servlet OU d'utiliser une couche de persistance?

---

Je dirais que cela dépend de tes compétences et de la création / utilisation des procédures stockées, si l'on parle de vitesse en terme de développement plutôt que d'exécution / performance.

Le fait d'utiliser une Servlet ou une couche de persistance permet juste de changer le découplement de ton application. Dans la mesure où tu devras faire appel à tes procédures stockées via JDBC, tu seras forcément amené à faire une couche de persistance. C'est juste que dans un cas, les Servlets utiliseront ta couche, plutôt que de faire directement des appels à la main. Je te conseille de réaliser une couche propre de persistance, afin d'augmenter la maintenabilité et de faciliter la réalisation de tests.

Ton application serait alors du type : Servlet -> Persistance (JDBC) -> MySQL

Citation:

---

Est ce intéressant de faire des web-services plutôt que des servlets ?

---

Faire des WS (REST) ou des Servlets ne changent pas grand chose. Il s'agit d'effectuer des requêtes HTTP d'un certain type (GET, PUT, ...) à une certaine URL. Réaliser le traitement dans une méthode doPut ou utiliser l'annotation @PUT de JAX-RS ne change pas grand chose en terme de développement, mis à part la connaissance des bibliothèques.

Je pense que tu devrais plutôt prendre en compte les deux points suivants :

1. Compétences / connaissances dans les Servlets et JAX-RS
2. Si tu as des types de données autre que du texte (XML / JSON ... inclus dans "texte") car les implémentations de JAX-RS offre pas mal d'abstraction pour les données comme les fichiers, ...

En tout cas, je t'invite à lire la documentation de RESTEasy ici qui présente plutôt bien JAX-RS, en plus des spécificités de RESTEasy.

Bon courage !

Bonjour, merci pour votre réponse,

J'ai de bonne connaissances en PL/SQL Oracle, je regarderais si sur mySQL ça se ressemble. Ceci étant dit je ferais comprendre au client l'enjeu de l'utilisation des procédures (non portabilité) et si cela colle je partirais sur cette solution.

Je t'avoue ne pas avoir bien compris pour la couche de persistance (je me fais surement une mauvaise définition de ce qu'est la persistance)

Sinon je vais partir sur des Servlets, si cela ne change pas grand-chose, je préfère assurer sur des outils que je maîtrise déjà pour mon premier projet. Toutefois je garde ton lien bien au chaud car il faut que j'ouvre mon esprit sur les différentes solutions (surtout en terme de serveurs).

Merci pour ton aide

Citation:

---

Néanmoins l'inconvénient majeur, selon moi, est la portabilité

---

C'est un inconvénient théorique. A partir du moment où un SGDB donne satisfaction, l'expérience montre que le changement de base de données est plutôt rare.
Par ailleurs, même si on n'utilise pas de procédure stockée, le code SQL n'est pas exactement le même d'une base à l'autre.
Par exemple si on veut avoir que les 10 premiers enregistrements on fait :
SELECT TOP 10 * FROM MaTable dans SQL Server
SELECT * FROM MaTable limit 10 dans MySQL
ceci veut dire que
- si on change de base SANS procédure stockée alors on doit réécrire la partie cliente en java
- si on change de base et qu'on utilise des procédures stockées de même nom alors la ré-écriture du code java est minimale

tout cela est bien théorique encore une fois. Même dans le cas de rachat d'entreprise utilisant des bases différentes, je les ai vu préférer conserver ce parc hétérogène et reculer devant le coût et le risque de la migration

Plop,

@Népomucène : Effectivement il s'agit d'une solution bien plus théorique qu'habituelle dans les entreprises.

Ce que j'entendais par couche est la façon dont tu vas concevoir les "composants" de ton application. Un composant permettant de se connecter et de requêter la base de données sera alors ta couche de persistance. Je t'invite à lire ce tutoriel sur un pattern standard pour gérer cela.

L'intérêt derrière est de découpler ton application en "modules" afin de pouvoir les tester et les modifier plus aisément.

Bon courage