Discussion :

[brousaille]

Bonjour a tous,

je suis en train de me former sous Struts, et je me pose une question en terme d'architecture. J'ai vu que dans les classes héritants de "Action" on pouvait faire un getDatasource afin de faire la connection a la Database.

Ca me chagrine de faire les ouvertures / fermetures/ Requete dans ces classes.

J'aimerai avoir une architecture comme ceci pour faire un insert ( un user par ex) :


Une classe UserService :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class UserService {
 
	 public boolean insertUser( UserDTO user) {
        //
        // INSERTION DE MON USER DANS LA DATABASE 
 
        //
    }
}

Une classe insertUserAction :

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
public final class InsertUserAction extends Action {
 
public ActionForward execute(ActionMapping mapping,
            ActionForm form,
            HttpServletRequest request,
            HttpServletResponse response)
			throws Exception {
						UserService = objService new UserService();
 
						UserDTO = objUserDTO new UserDTO();
 
						objService.insertUser( objUserDTO );
 
//.........
			}
 
}

Donc vous l'aurez compris j'aimerai que tout mes acces base de données se fassent dans mes objets de Service et non dans mes actions.
Seulement mon GetDataSource n'est pas disponible dans mes services, a moins qu'ils héritent eux aussi de "Action" mais j'aimerai autant pas, afin qu'il reste le plus indépendant possible.

Avez vous une idée pour m'aider a resoudre cette impasse

Merci par avance

B.

[viena]

Pour commencer, c'est une tres bonne idée de ne pas ouvrir de connexion dans les actions. En effet, c'est déconseiller car les action sont multithreadées et qu'il faut vraiment etre tres rigoureux si on ne veut pas avoir d'ennui. La séparation des couches est donc une excelente idée.

Moi je n'utilise pas de getDatasource, je n'ai donc pas de solution toute préte, mais au pire, tu peux faire ton getDataSource dans ton action et l'envoyer à ton service (via le constructeur par exemple...)

[dlemoing]

En effet, c'est déconseiller car les action sont multithreadées et qu'il faut vraiment etre tres rigoureux si on ne veut pas avoir d'ennui. La séparation des couches est donc une excelente idée.

Je ne suis pas d'accord pour dire que le fait que les action soient multithreadées soit un véritable problème. Je ne pense pas qu'il soit au dessus des moyens d'un développeur de produire un code thread-safe.
Par contre, une architecture multicouche avec une séparation des responsabilités est un bon choix et c'est pour cette raison que tu ne dois pas travailler dans ton action avec un datasource. L'action doit contenir le moins de code possible et déléguer au domaine métier toute la logique de l'application.
C'est dans la couche liée à la notion de persistance que tu devras récuperer le DataSource. Pour cela, je te conseille de te coder une classe helper qui saura retrouver le datasource et obtenir une Connection. Si tu veux te faciliter la vie avec JDBC, regarde du coté de dbutils ou de Spring JDBC.

[austin P.]

tu peux aussi regarder du coté des systèmes de mapping objet/relationnel type hibernate, jdo,...

[brousaille]

Merci a tous de vos réponses,
Je n'ai pas envie pour le moment d'utiliser des frameworks genre hibernate, j'aimerai bien essayer de codé l'acces a la couche de donnée moi meme.
Dlemoing tu m'orientes vers le coding d'une couche Helper. Ca me parrait une bonne idée .......... mais tu aurais des exemples ?

[JnJp28]

Pour mart je pense que tu dois séparer ta partie accès des données.
Pour cela tu créé une session facade entres ta couche metier et les objets transactionnel. Par exemple :
1->DB
2->EJB entity
3->EJB Session
4->Session facade
5->Struts (action,vue)

[dlemoing]

EJB ENTITY !!!!!!!! NOOOOOOOOOOOOOOOOOOOOOOOOOOOOON !!!!
D'ailleurs pourquoi utiliser des EJB ? J2EE != EJB.
Les EJB, c'est comme les anti-biotiques, c'est pas automatique (d'ailleurs j'ai développé une certaine résistance).
Pour des exemples, je peux t'en donner mais ca va te faire peur (car bien plus évolués que ce que tu souhaites), cherche plutot sur le net des exemples simples de récupération d'un DataSource depuis JNDI.

Pour mart je pense que tu dois séparer ta partie accès des données.

La dessus on est d'accord par contre, c'est d'ailleurs ce que je voulais dire en parlant d'une couche liée à la persistance.

[brousaille]

Je pensais faire une classe statique, avec des variables statiques qui contienne toutes les informations pour se connecter a la base. Cette classe serait initialiser au lancement de l'application. Et comme elle est statique elle sera disponible de partout........ c'est surement simple comme solution mais ca doit peut etre marcher faut que j'essaye

[JnJp28]

Les EJB, c'est comme les anti-biotiques, c'est pas automatique (d'ailleurs j'ai développé une certaine résistance).

Ok je suis d'accord, c'etait juste un exemple de separation des couches.
Il peut aussi faire du JDBC mais l'important et ca tu es d'accord depuis le debut c'est que le code metier ne doit pas dépendre de la base de données.

Merci.

[austin P.]

Pour des exemples, je peux t'en donner mais ca va te faire peur (car bien plus évolués que ce que tu souhaites), cherche plutot sur le net des exemples simples de récupération d'un DataSource depuis JNDI.

mouais
utiliser une datasource c'est quand meme un peu de "bas niveau".
je m'explique : un système de persistance en utilisant le pattern DAO+SQL c'est pas mal mais il faut pisser du code et ce d'autant plus qu'il y a de bases de données de destination.

utilise plutot un système de mapping objet/relationnel
ces systèmes proposent des mécanismes avancés (verouillage, cache objet, TTL des objets dans le cache, etc...)

[brousaille]

tu veux parler d'un framework type Hibernate ?

[dlemoing]

mouais
utiliser une datasource c'est quand meme un peu de "bas niveau".

Utiliser une datasource c'est bas niveau ? J'aimerais connaitre tes critères de jugement.

je m'explique : un système de persistance en utilisant le pattern DAO+SQL c'est pas mal mais il faut pisser du code et ce d'autant plus qu'il y a de bases de données de destination.

Penses tu réellement que dans le cadre d'une application d'entreprise, dans laquelle il y a eu un véritable engagement sur une technologie de base de données, on pense à écrire du code pour tout type de base de données ? (Je me vois mal faire du MySQL dans une boite qui a tout misé sur Oracle) Je crois que tu fais une grosse erreur sur ce point. Le DAO définit une interface à implémenter pour l'accès aux données. Libre à toi de définir une implémentation abstraite commune à différentes bases et isoler certaines requetes spécifiques dans des sous-classes.
Quand tu parles de pisser du code, je suis d'accord avec toi si tu parles d'une utilisation directe de JDBC. Pour moi, cela est à éviter, il vaut mieux passer par un framework qui te laisse un maximum de possibilités et le controle sur le SQL (voir Spring JDBC).

utilise plutot un système de mapping objet/relationnel
ces systèmes proposent des mécanismes avancés (verouillage, cache objet, TTL des objets dans le cache, etc...)

Je n'ai absolument rien contre l'ORM et si tu regardes sur le forum tu verras qu'il m'arrive de répondre à des questions sur Hibernate. Cependant, il n'y a pas UNE solution à tous les problèmes, il faut considérer les situations au cas par cas. Si l'appli ne bénéficie pas de l'ORM, s'il n'existe aucune expérience sur le sujet, s'il existe une forte expérience en SQL et sur une technologie de base de données, pourquoi ne pas tirer partie directement du SQL ?
De plus, tu ne tiens pas compte de la remarque qui a été faite :

Je n'ai pas envie pour le moment d'utiliser des frameworks genre hibernate, j'aimerai bien essayer de codé l'acces a la couche de donnée moi meme.

[austin P.]

Utiliser une datasource c'est bas niveau ? J'aimerais connaitre tes critères de jugement.

tout simplement qu'il existe des mécanismes, tel que les frameworks de mapping et je ne vois pas l'intérêt d'utiliser directement une datasource

dans le meme esprit qu'il existe JDBC tu ne vas pas réecrire un système d'accès meme si il est optimisé par rapport à tes besoins

Penses tu réellement que dans le cadre d'une application d'entreprise, dans laquelle il y a eu un véritable engagement sur une technologie de base de données, on pense à écrire du code pour tout type de base de données ? (Je me vois mal faire du MySQL dans une boite qui a tout misé sur Oracle) Je crois que tu fais une grosse erreur sur ce point.

faux
beaucoup d'entreprise utilise des SGBDR différents suivant leurs besoins
j'en veux pour preuve mon expérience de 8 ans et des nombreuses entreprises où je suis intervenu.
les changements de stratégies au cours du projet j'ai déjà gouté et c'est loin d'être un cadeau.

Le DAO définit une interface à implémenter pour l'accès aux données. Libre à toi de définir une implémentation abstraite commune à différentes bases et isoler certaines requetes spécifiques dans des sous-classes.

c'est justement ce que j'appelle pisser du code
il faut concevoir, tester et je te parle pas du cout de la maintenance évolutive. Vu le prix d'une journée de dev c'est un paramètre à prendre en compte.

Quand tu parles de pisser du code, je suis d'accord avec toi si tu parles d'une utilisation directe de JDBC. Pour moi, cela est à éviter, il vaut mieux passer par un framework qui te laisse un maximum de possibilités et le controle sur le SQL (voir Spring JDBC).

là on est daccord

Je n'ai absolument rien contre l'ORM et si tu regardes sur le forum tu verras qu'il m'arrive de répondre à des questions sur Hibernate. Cependant, il n'y a pas UNE solution à tous les problèmes, il faut considérer les situations au cas par cas. Si l'appli ne bénéficie pas de l'ORM, s'il n'existe aucune expérience sur le sujet, s'il existe une forte expérience en SQL et sur une technologie de base de données, pourquoi ne pas tirer partie directement du SQL ?

je ne pense pas que l'immobilisme sur les technologies soient un critère. Il est certains que l'acquisition d'une technologie prend du temps. Mais c'est du temps de gagné ensuite (toujours à comparer au cout d'une journée de dev).

De plus, tu ne tiens pas compte de la remarque qui a été faite :

Je n'ai pas envie pour le moment d'utiliser des frameworks genre hibernate, j'aimerai bien essayer de codé l'acces a la couche de donnée moi meme.

c'est une réflexion que j'avais aussi....
avant de gouter au mapping

[dlemoing]

tout simplement qu'il existe des mécanismes, tel que les frameworks de mapping et je ne vois pas l'intérêt d'utiliser directement une datasource

dans le meme esprit qu'il existe JDBC tu ne vas pas réecrire un système d'accès meme si il est optimisé par rapport à tes besoins

Tu vois trop, je pense, l'ORM comme l'UNIQUE solution.

faux
beaucoup d'entreprise utilise des SGBDR différents suivant leurs besoins
j'en veux pour preuve mon expérience de 8 ans et des nombreuses entreprises où je suis intervenu.
les changements de stratégies au cours du projet j'ai déjà gouté et c'est loin d'être un cadeau.

Ayant eu l'expérience inverse, on ne va pas considérer l'une ou l'autre des expériences comme une généralité...preuve encore une fois que le choix peut dépendre du contexte. Dans le contexte que tu cites, je pense que c'est la "stratégie" qui est questionnable, mais bon...on n'a pas toujours le choix.

c'est justement ce que j'appelle pisser du code
il faut concevoir, tester et je te parle pas du cout de la maintenance évolutive. Vu le prix d'une journée de dev c'est un paramètre à prendre en compte.

Je ne vois pas le problème des tests. S'ils sont fait sur des interfaces de DAO il n'y a rien de plus à faire, juste les faire passer et regarder le résultat...

je ne pense pas que l'immobilisme sur les technologies soient un critère. Il est certains que l'acquisition d'une technologie prend du temps. Mais c'est du temps de gagné ensuite (toujours à comparer au cout d'une journée de dev).

Parceque tu n'as jamais rencontré de personnes réfractaires aux changements ? De plus, tu "sembles" ignorer (je me doute bien que non) le fait que le choix d'une technologie doit se faire sur des critères. Pourquoi s'embeter avec de l'ORM pour un outil de reporting ? Je ne dis pas que les outils d'ORM ne fournissent pas de solutions pour ce genre de problèmes mais il faut bien avouer que dans ce contexte, l'ORM est plus pénible qu'autre chose. La taille du projet et la complexité de l'accès aux données sont également à prendre en compte. Si par contre, je veux développer un vrai Domain Model, tirer partie des solutions de mise en cache ou d'autres mécanismes fournis par les outils ORM alors il ne faut pas se priver d'hibernate, JDO, TopLink...

c'est une réflexion que j'avais aussi....
avant de gouter au mapping

Je ne cherche pas à te convaincre d'abandonner l'ORM. Moi même je pratique et j'apprécie cette solution quand elle est bien employée (et ce n'est pas toujours le cas). Toutefois, ce n'est pas la voie obligatoire pour toute appli.

[austin P.]

Tu vois trop, je pense, l'ORM comme l'UNIQUE solution.

non
simplement que je n'utilise pas l'ORM si il existe des contraintes particulières : la performance optimale par exemple
mais sinon pourquoi se priver

Ayant eu l'expérience inverse, on ne va pas considérer l'une ou l'autre des expériences comme une généralité...preuve encore une fois que le choix peut dépendre du contexte. Dans le contexte que tu cites, je pense que c'est la "stratégie" qui est questionnable, mais bon...on n'a pas toujours le choix.

exact : tu n'as pas le choix, le client est roi
c'est pour cela que l'ORM permet une souplesse que n'offre par JDBC

Je ne vois pas le problème des tests. S'ils sont fait sur des interfaces de DAO il n'y a rien de plus à faire, juste les faire passer et regarder le résultat...

le problème ne vient pas des tests mais du résultat : tu codes peut être nickel du premier coup, moi ce n'est pas mon cas. Donc tu testes, tu corriges, tuvalides, etc. tout cela c'est du temps et donc de l'argent.
en plus la moindre modif du modèle physique ou modèle objet entraîne systématiquement des tests aussi bien techniques que fonctionnels. Encore du temps...
avec l'ORM je m'arrête aux tests fonctionnels.

Parceque tu n'as jamais rencontré de personnes réfractaires aux changements ? De plus, tu "sembles" ignorer (je me doute bien que non) le fait que le choix d'une technologie doit se faire sur des critères. Pourquoi s'embeter avec de l'ORM pour un outil de reporting ? Je ne dis pas que les outils d'ORM ne fournissent pas de solutions pour ce genre de problèmes mais il faut bien avouer que dans ce contexte, l'ORM est plus pénible qu'autre chose. La taille du projet et la complexité de l'accès aux données sont également à prendre en compte. Si par contre, je veux développer un vrai Domain Model, tirer partie des solutions de mise en cache ou d'autres mécanismes fournis par les outils ORM alors il ne faut pas se priver d'hibernate, JDO, TopLink...

euh là je sais pas trop quoi dire
si les personnes sont réfractaires au changement, il en sont encore au cobol...
je crois que si il existe une profession où le changement est constant, c'est bien la notre.
Le reporting fait partie des cas très particuliers c'est vrai
mais vu les exemples de brousaille je dirais qu'on a plutot à faire à une appli de gestion

Je ne cherche pas à te convaincre d'abandonner l'ORM.

ouf j'ai eu peur

Moi même je pratique et j'apprécie cette solution quand elle est bien employée (et ce n'est pas toujours le cas). Toutefois, ce n'est pas la voie obligatoire pour toute appli.

ce n'est pas mon propos
je dis simplement que par défaut j'utilise un ORM sauf si cas très particulier

[dlemoing]

non
simplement que je n'utilise pas l'ORM si il existe des contraintes particulières : la performance optimale par exemple
mais sinon pourquoi se priver

Heureux de l'entendre.

exact : tu n'as pas le choix, le client est roi
c'est pour cela que l'ORM permet une souplesse que n'offre par JDBC

Je ne suis pas forcement d'accord, mais bon, admettons. C'est peut être sur l'endroit où tu situes la souplesse que je ne suis pas d'accord.

le problème ne vient pas des tests mais du résultat : tu codes peut être nickel du premier coup, moi ce n'est pas mon cas. Donc tu testes, tu corriges, tuvalides, etc. tout cela c'est du temps et donc de l'argent.
en plus la moindre modif du modèle physique ou modèle objet entraîne systématiquement des tests aussi bien techniques que fonctionnels. Encore du temps...
avec l'ORM je m'arrête aux tests fonctionnels.

Tu veux donc dire que tu ne testes pas ta partie persistance parceque tu as une confiance aveugle en l'ORM ? Je n'ai jamais dit que je ne testais pas. Seulement, mes tests se font sur l'interface de mon DAO et je suis libre de tester une implémentation avec JDBC ou Hibernate. De plus, j'adopte une démarche basée sur le Test Driven Development. Pour moi, ils sont aussi important que le code de mon appli et je ne les considère pas comme une source de cout mais plus comme un outil de qualité.

Le reporting fait partie des cas très particuliers c'est vrai mais vu les exemples de brousaille je dirais qu'on a plutot à faire à une appli de gestion

Donc tu admets plus ou moins que tu utilises l'ORM dans le cadre d'appli de gestion et qu'il existe des cas pour lesquels ce n'est pas adapté, on est d'accord ?

je dis simplement que par défaut j'utilise un ORM sauf si cas très particulier

C'est une facon de voir les choses que je respecte totalement, il faut juste être suffisament clairvoyant pour adopter une autre solution si le besoin l'impose (je précise ca parceque j'ai rencontré des gens qui restaient bloqués sur une et une seule archi quelque soit le besoin).

Pour finir d'éclaircir mon propos, je précise que j'adopte un peu la même démarche que toi parceque je trouve dommage de se passer de la puissance des outils ORM. C'est généralement la meilleure solution pour commencer un Domain Model riche sans trop d'efforts.
Par défaut, c'est également le choix vers lequel je me tourne sauf cas bien particuliers :
- appli qui visiblement ne bénéficiera pas de l'ORM (pas adapté, accès simple en base),
- compétences en interne (Java, DP, frameworks),
- attachement à la base de données et fortes compétences (SQL, base do).

La seule différence que je ferais avec toi, c'est que je ne jeterais pas si vite le SQL (je ne parle pas de JDBC qui doit être masqué par une couche d'abstraction type Spring JDBC). Il a largement sa place dans bon nombre de projets qui ne bénéficient pas d'un Domain Model ou sont relativement simples en terme d'accès en base.

[austin P.]

tu veux parler d'un framework type Hibernate ?

oui

[austin P.]

Tu veux donc dire que tu ne testes pas ta partie persistance parceque tu as une confiance aveugle en l'ORM ?

euh oui
comme je fais confiance à ma JVM, mon OS, etc..
sinon la on s'en sort plus
je me répete mais mes tests sont uniquement fonctionnels

Je n'ai jamais dit que je ne testais pas. Seulement, mes tests se font sur l'interface de mon DAO et je suis libre de tester une implémentation avec JDBC ou Hibernate. De plus, j'adopte une démarche basée sur le Test Driven Development. Pour moi, ils sont aussi important que le code de mon appli et je ne les considère pas comme une source de cout mais plus comme un outil de qualité.

peu importe la méthode
les tests coutent cher et les raccourcir est très appréciable

Donc tu admets plus ou moins que tu utilises l'ORM dans le cadre d'appli de gestion et qu'il existe des cas pour lesquels ce n'est pas adapté, on est d'accord ?

ouaip

- compétences en interne (Java, DP, frameworks),

arrrggghh
là je coince
une petite assistance technique d'une semaine et le tour est joué
en plus la presta est pas cher en ce moment, profitez des soldes

bon sinon on est presque daccord en fait
du coup on a oublié le pauvre brousaille :-)

[brousaille]

Non Non mais je suis de pres tout ca !!!