probleme d'architecture avec JDBC

**othmanehayat** · 11/11/2008, 11h44

bonjour,

en fait j'ai effectué la connexion à une BDR via jdbc dans une architecture 2-tiers et j'aimerai savoir quel sont les inconveinients de l'architecture 2-tiers lorqu'on utilise JDBC.

et merci.
cordialement

**Tsunamy** · 12/11/2008, 12h25

1. des problèmes de contrôle des évolutions : si on modifie la base (modifier le type d'un champ d'un table, ...) on doit mettre à jours le programme client.

2. il faut avoir autant d'accès protégé par mot de passe que d'accès serveurs.
3. Corrolaire à la spécificité du logiciel client vis à vis du serveur : l'aspect propriétaire de l'application client. Le marché de l'informatique se caractérise par volatilité de certaines de ses entreprises qui n'ont pas de fait une très longue pérénité. Dans ce contexte et ces contraintes, la question de la viabilité à long terme, d'une application client propriétaire, est un élément significatif à prendre en compte dans le choix d'une architecture 2-tiers.

**OButterlin** · 12/11/2008, 14h06

Il n'y a pas vraiment de problèmes spécifiques à cette architecture.

L'application est un peu plus difficile à maintenir dans la mesure où JDBC est fortement déconnecté du type réel d'une donnée (je veux dire par là que dans le programme on peut coder un rs.getDouble(...), ça ne posera pas de problème en soit avant l'exécution si le type réel est String)

Maintenant, quand on change le type d'une colonne, il est extrêmement rare qu'il n'y ait pas de répercussion dans le programme. L'avantage d'un framework comme Hibernate réside dans le fait qu'on travaille avec des propriétés typées et que lors d'un changement, c'est le compilateur qui signalera les erreurs...

On peut faire quelque chose de très proche avec JDBC en codant des classes de données (dans l'esprit des EJB BMP)

Pour ce qui est du nombre de points d'entrée sur le serveur (point 2 de Tsunamy), il n'y en a qu'un !

Bref, pour moi, ça reste une approche correcte...

A+