Version imprimable
Laquelle des méthodes préférées vous ; avantages et inconvénients
-HibernateTemplate
-JdbcTemplate
-ou JPA
J'avoue que je n'arrive pas à me décider.
cependant selon mon point de vue:
-JPA
avantages: semble assez simple moins d'effort
inconvénients: mono utilisateur
-JdbcTemplate
inconvénients: bcp de codes
-HibernateTemplate
Pourquoi JPA serait mono utilisateur ?
Du moins c'est ce que je crois.L'utilisation de entityFactory n'engendre t'elle pas une seule type qe connection à la bd avec les mêmes droits sur les objets. l'impossibilité de distingué deux utilisateurs différents.
Dans ce cas là, il te faudra autant d'EntityManager que de User mais je ne pense pas que cela soit une bonne idée de le gérer comme ça, si c'est bien une application web.
ne mélangez pas "application's users" et "RDBMS's user" …Citation:
Envoyé par yLaplace
la gestion des rôles dans l'application peut se gérer via des frameworks tel que Spring-security…
la gestion des rôles de la DB est du ressort du DBA…
vouloir réutiliser les utilisateurs définis au niveau de la database au niveau de l'application n'est pas à conseiller… à moins que l'application elle-même soit un outil d'admin du RDBMS… auquel cas la sécurité sera réglée aussi par la configuration réseau…
Si je ne m'abuse, je pense que si, les utilisateurs (login,mp) defini au niveau de la bd doivent être utilisés au niveau applicatif comme le fait les gros system tq Oracle. Ds Oracle, les utilisateurs définis au niveau du bd sont ceux qui sont habilités à utiliser l'application ( ça fait part de la sécurisation de l'appli). moi j'opte plus pour cela car un inconnu du systeme ne pourra pas l'utiliserCitation:
Envoyé par JeitEmgie
"doivent" : définitivement nonCitation:
Envoyé par yLaplace
"peuvent" : dans certains cas… si nécessaire et qu'il n'y a pas moyen de faire autrement par rapport aux fonctionnalités requises…
n'oubliez pas qu'un utilisateur qui a un login d'accès à la DB peut utiliser un outil d'administration (TOAD, SQLDeveloper, Navicat, …) et voir le contenu des tables, et éventuellement manipuler leur contenus SANS passer par la couche applicative qui est là pour veiller à ce que les règles business soient respectées…
ce n'est pas une question de taille de système…
et quand vous sécurisez une application avec une couche comme spring-security : aucun "inconnu" du système n'aura accès à autre chose que ce que VOUS déciderez qu'un "guest" à le droit de voir…
concernant l'utilisation de toads et autre outils, je suis désolé. Je travaille moi même sur toads et je vais te dire que cela depend de ses privilèges; s'il n'a aucun privilège sur les tables même en se connectant avec toad il ne vera rien. Quelque soit l'outil qu'il utilise il ne pourra faire que ce que ses privilèges lui permettre de faire.Citation:
Envoyé par JeitEmgie
Je rappelle qu'à la création d'un utilisateur on ne lui accorde pas le rôle DBA.
On est d'accord pour un outil comme Toad comme l'a dit JeitEmgie.
En revanche pour une application web, on utilise généralement un user de base générique. Les autorisations sont faites au niveau applicatif.
la gestion au niveau applicatif avec certainement Spring-security.Citation:
Envoyé par fr1man
Et dans le cas d'une application non web je veux dire par exemple application Swing?
est-ce que vous vous rendez compte que vous tournez en rond… et que vous changez de sujet à chaque post ?Citation:
Envoyé par yLaplace
évidemment, La Palice en aurait dit autant, qu'un login sans privilège ne pose pas de problème de privilège… mais il ne permet pas non plus de faire grand chose au niveau de l'application… à part du reporting…
pour revenir à l'origine du thread, votre "JPA monoutilisateur" : c'est un argument non pertinent !