Discussion :

[pontus21]

Bonjour à tous,

Je dois développer une appli qui interagisse avec une base de données MySQL.
J'aimerais savoir ce que vous me conseilleriez et les principales différences entre une appli standard, une applet, une servlet ... ? (Et peut-être d'autres types que je ne connais pas ...)

Pour le moment, je n'ai fait que des applis standards.
D'ailleurs y a-t-il de grandes différences entre les différents types de développement ?

Je précises que mon appli devra être exécuté sous Mac principalement mais aussi sous Windows !

Merci d'avance pour vos réponses.

[tchize_]

standalone (ce que tu fais) tu va utiliser du swing ou de l'awt (la pluspart du temps) et avoir accès aux ressources locales de l'utilisateur

applet: vaguement similaire au standalone, tu va pouvoir faire une interface graphique que tu lance depuis une page web. Pour des raisons de sécurités, tu aura des accès très limités au système de l'utilisateur. Pas d'accès à ce qui est confidentiel, au système de fichier ou au réseau, à l'exception d'un accès autorisé quand meme vers le serveur qui a fournis l'applet. Tu peux contourner ces limitation en signant l'applet pour la certifier en ton nom. L'utilisateur aura alors une boite de dialogue demandant si il fait confiance à l'applet

webstart: application standalone, mais distribuée et mise à jour automatiquement via le réseau. Aussi à signer pour avoir accès au système local (comme pour les applets), mais ne nécessite pas nécessairement de browser pour tourner.

servlet/jsp: code s'exécutant sur un serveur, n'a a priori pas d'utilité de awt et swing, destiné principalement à fournir des pages html ou aufre fichiers que les browser utilisent (vaguement similaire sur le principe à du php). Destiné à faire des sites dynamique et des applications web. En plus de l'api standard, tu as accès là à des api spécifique pour le web.

java mobile: applications standalones destinées à des appareils mobiles, elle ont un accès à un api java limitée et spécifique. La jvm se comporte aussi différement

[Fichman]

Salut,

Pour le type d'appli, ben ça dépend ...
Mais si ton appli doit être utilisé par beaucoup de monde, autant faire une appli Web avec des frameworks du type Struts & Co. Au moins tout sera centralisé. Mais rien ne t'empêche de faire un client lourd.

Pour les applis Web, c'est sur qu'il y a des différences de conception (pages Web, plus de Swing ou autre AWT), mais après du java ça reste du java.

[pontus21]

Et autre question.

Si je développe une appli standalone, est-ce ensuite difficile et compliqué de modifier en applet ou servlet ??

[adiGuba]

Salut,

webstart: application standalone, mais distribuée et mise à jour automatiquement via le réseau. Aussi à signer pour avoir accès au système local (comme pour les applets), mais ne nécessite pas nécessairement de browser pour tourner.

A noter qu'on dispose alors d'un package supplémentaire (javax.jnlp) qui permet l'accès à certains services (téléchargement, système de fichiers, presses-papiers, impression) de manière limité mais sécurisé pour l'utilisateur. Ce qui selon les cas peut permettre d'utiliser une application non-signé (même si dans le cas d'un accès à un BD je pense que cela doit être nécessaire).

Si je développe une appli standalone, est-ce ensuite difficile et compliqué de modifier en applet ou servlet ??

La migration applet/standalone peut être assez facile. Le même Jar pourrait d'ailleurs être à la fois distribué en applet et en standalone...

Pour les servlet c'est autre chose : il s'agit d'une application tournant sur le serveur et non pas sur le poste client. Donc pas d'application graphique standard (Swing/AWT). Pour l'interface on utilise généralement un client léger (un navigateur internet), ce qui fait que toute l'interface est à revoir.

Mais bien sûr les classes métiers sont tout à fait réutilisable...


a++

[tchize_]

Mais bien sûr les classes métiers sont tout à fait réutilisable...

Avec le bémol quand meme que certains comportements sont à éviter et qu'il faut y porter un soins particulier en servlet, je pense par exemple à la gestion de Thread, à tout ce qui joue avec des ThreadLocal ou touche à la gestion de la mémoire

[slevy]

Bonjour,
Je te conseille clairement de faire l'appli en Java J2EE (java côté serveur) en utilisant les frameworks open source du marché (Struts, Spring, Hibernate...).
C'est le type d'application le plus utlisé en entreprise, donc l'expérience que tu vas en tirer sera optimum.

Il existe un template tout fait qui accède déjà à une base mySQL en utilisant ces frameworks :
http://raibledesigns.com/rd/entry/an...x_1_5_released

Il suffit de s'en inspirer (après l'avoir un peu étudié quand même) et quelques modifications permettent d'accèder à n'importe quelle base.

Stéphane

[tchize_]

Bonjour,
Je te conseille clairement de faire l'appli en Java J2EE (java côté serveur) en utilisant les frameworks open source du marché (Struts, Spring, Hibernate...).
C'est le type d'application le plus utlisé en entreprise, donc l'expérience que tu vas en tirer sera optimum.

Le fait que c'est le plus utilisé ne devrais pas être un argument de choix, le premeir argument du choix devrait être les besoins du clients. Certes une appli web est plus facilement multi utilisateur qu'une appli standalone, mais le standalon a l'avantage de la grande richesse des composants graphique et de ne pas devoir centraliser les sessions sur un seul serveur.

Il y a aussi la possibilité de fournir un webservice centralisé pour distribuer les données et avoir des applis standalone qui s'y connectent. T'as aussi les EJB qui permettent d'avoir des applis standalone.

Par contre, une recommendantion, ne pas mettre le connecteur SQL du coté des clients, (c'est pas une obligation absolue mais une recommendation) de manière à pouvoir limiter l'accès au serveur SQL à quelques machines privilégiées.

[pontus21]

Je pense que je vais me diriger vers une appli stand-alone ...

Le problème c'est que le code va être côté client, et donc visible ...
Je me trompe ?

Si je me trompe pas, qu'est-ce qui pourrait me "sécuriser" le code ?

[tchize_]

on ne "sécurise" pas le code, on sécurise le serveur, ce qui est coté client doit être ce qui peut etre transmis sans risque. En l'occurence, ici, il faudra que chaque client aie son propre compte sur la db et que la db soit configurée pour que les clients ne sachent pas faire plus que ce qu'ils ne peuvent et garde, éventuellement, des traces.

[pontus21]

on ne "sécurise" pas le code

Je veux dire par là que le code ne doit pas être visible par le client (si possible, bien sûr).
Car avec une appli standalone, je vais créer un jar (ou alors peut-être y a-t-il autre chose que je ne connais pas ...) mais ce jar contient le code qui peut être lu directement par l'utilisateur.
Ce que j'aimerais éviter ...

[guigui5931]

Dans un jar tu met les .class (qui ne sont pas lisible directement). Dans tout les cas tu sera obligé de donner une partie du code à ton client (et ceux quel que soit le langage). Le code pourra toujours être décompilé. C'est pour ça qu'il faut que tu mette le moins de chose possible coté client, créer des comptes de base de données séparés.
Il y a des moyens de rendre le code plus dur à décompiler (obfuscation, ...) mais ce n'est pas une solution miracle.

[tchize_]

et en plus, l'obfuscation rend impossible l'utilisation de stacktraces pour débugger les erreurs trouvées par les utilisateurs puisque le stacktrace n'a plus aucun sens