[Architecture] Question data layer et présentation

Bonjour à tous,

je m'apprete a developper une application j2ee. Mon premier pb qui se pose est dans le choix de l'architecture. Pour ca je veux avoir ma couche de présentation, ma couche business et ma couche d'acces au donnée.

Pour la présentation je veux utiliser Struts. Pour ne pas mélanger les differentes couches je ne veux pas faire mes appels a la base de donnée dans les les classes Action......(c possible avec la datasource de Struts) Mais du coup je sais pas comment pouvoir rendre accessible ma base de donneé dans ma couche métier.

Auriez des exemples ou des idées. Je ne veux pas utiliser Hibernate. On m'a parler d'utiliser le pool de connection de tomcat.... Mais je ne vois pas comment faire pour l'implémenter dans ma de donnée métier sachant que j'aimerai qu'elle soit indépendante ( donc qu'elle n'herite pas des classes Servlets..).

Aussi si j'utilise cette méthode je reste completement dépendant de TOMCAT non ?

Je sais pas si je me suis bien exprimé, mais si vous avez compris je veux bien de l'aide !!! :?

Salut,

il faut que tu découvres Spring. Ce framework permet de rendre indépendant toutes tes couches. Le fichier de configuration Spring permet d'effectuer un maillage de tes couche (binding).

Le truc important est que tu conçoives des interfaces pour tes services afin d'être indépendant de l'implémentation. C'est ce qui garantira la flexibilité de ton application.

Sur le site même tu as pas mal de ressources Spring (Tutoriel Serge Tahé, Tutoriel CRUD Spring).

Si tu as besoin d'aide pour le maillage Struts - Métier avec Spring fais le moi savoir par MP ou bien peut-être dlemoing pourra t'aider (il est bien meilleur spécialiste de Spring que moi ;)).

Bon courage

Merci Sleepy de ta réponse,

mais j'ai vraiment pour contrainte d'utiliser Struts........ Je n'ai jamais utiliser Spring et il est vrai que je n'ai pas trop le tps d'aprehender une nouvelle technologie.

Mais d'apres ce que tu décris je crois que je vais aller jeter un oeil juste par curiosité, mais je ne pourrai pas l'utiliser dans ce projet.

B.

Citation:

---

Envoyé par brousaille

Merci Sleepy de ta réponse,

mais j'ai vraiment pour contrainte d'utiliser Struts........ Je n'ai jamais utiliser Spring et il est vrai que je n'ai pas trop le tps d'aprehender une nouvelle technologie.

Mais d'apres ce que tu décris je crois que je vais aller jeter un oeil juste par curiosité, mais je ne pourrai pas l'utiliser dans ce projet.

B.

---

Spring peut en effet être utilisé comme framework MVC, mais en l'occurence nous te proposons de l'utiliser pour abstraire les couches.
(Pardon à la ligue de défence des schéma ascii)


Présentation (JSP, HTML, Js, CSS)
Controller (Action)
|
Spring
|
Business (POJO)
|
Spring
|
DAO (Hibernate ou JDBC)



En fait tu vas définir une interface pour la classe business et une pour la classe DAO. Apres grace au fichier de config spring tu va pouvoir définir'implémentation de cette interface. Ainsi dans la couche de présentation/controler tu fera appel a l'objet instancier par spring sans connaitre ses detrails d'implémentations et de même entre le business et le DAO.

Cependant dans le principe tu peux faire sans spring.
Simplement en faisant une classe qui contient tes meéthodes business qui pourrait (c'est mieux) être un singleton et de même pour la couche dao

Citation:

---

Envoyé par ze_key

Spring peut en effet être utilisé comme framework MVC, mais en l'occurence nous te proposons de l'utiliser pour abstraire les couches.
(Pardon à la ligue de défence des schéma ascii)


En fait tu vas définir une interface pour la classe business et une pour la classe DAO. Apres grace au fichier de config spring tu va pouvoir définir'implémentation de cette interface. Ainsi dans la couche de présentation/controler tu fera appel a l'objet instancier par spring sans connaitre ses detrails d'implémentations et de même entre le business et le DAO.

---

BOn je vais quand meme jeter un coup d'oeil sur cette affaire ;-) vous me vendez bien le truc la !!!

Citation:

---

Cependant dans le principe tu peux faire sans spring.
Simplement en faisant une classe qui contient tes meéthodes business qui pourrait (c'est mieux) être un singleton et de même pour la couche dao

---

Mais justement la couche DAO, il faut qu'elle puisse avoir une méthode du genre getConnection(). Et c'est la ou j'ai du mal a implémenter la chose, car je sais pas comment faire pour que ma getConnection me renvois quelque chose. Comment charger la connection ???

Citation:

---

Envoyé par brousaille

BOn je vais quand meme jeter un coup d'oeil sur cette affaire Wink vous me vendez bien le truc la !!!

---

C'est en effet un très bon choix.

Citation:

---

Envoyé par brousaille

Mais justement la couche DAO, il faut qu'elle puisse avoir une méthode du genre getConnection(). Et c'est la ou j'ai du mal a implémenter la chose, car je sais pas comment faire pour que ma getConnection me renvois quelque chose. Comment charger la connection ???

---

L'idée, c'est de conserver la meme connection le temps d'une transaction. Le plus souvent, il est bon que cette gestion des transactions se fassent au niveau de l'interface de services.
Je vais prendre l'exemple de ce qui est fait dans spring pour que tu comprennes bien ce que tu dois faire :
1- on définit un proxy transactionnel autour du service. Ce proxy a la charge de commencer une transaction (et donc une connection) de lancer le traitement (délégation au service) et de commiter ou rollbacker.
2- le service utilise généralement une couche d'accès aux données transactionnelles qui aura besoin de la connection. Pour cela, Spring utilise un systeme de template qui détecte si une connection a été ouverte pour la réutiliser (ou en crée une nouvelle).
3- la connection est gardée dans un objet ThreadLocal accessible par le proxy transactionnel et le template.

Si tu souhaites faire un JDBC, je te conseille d'utiliser le JdbcTemplate fournit par Spring qui t'évitera bien des problèmes et rendra ton code plus propre et compréhensible. De plus, si tu utilises la gestion transactionnelle de spring, tu ne feras plus jamais marche arrière.

PS : désolé si je suis pas très clair, j'ai pas trop le temps de détailler

Merci bien de cette réponse, mais je t'avoue que j'ai pas tout compris ;-) tout e ces notions !! Je crois que j'ai pas d'autre choix que de regarder Spring !!!

Mais le truc c'est que je voulais faire quelque chose de simple, et la j'ai l'impression que je m'avance vers une usine a gaz :lol: Ca me parrait vraiment dur a apprehender tout ca, comment faisait on sans Spring ?
:?

Moi je voyais un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10

public class UserService {   public boolean insertUser( UserDTO user) { // // INSERTION DE MON USER DANS LA DATABASE   // [color=red] Connection conn = getConnection()[/color] } }

---

Une classe insertUserAction :

Code:

---

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 );   //......... }   }

---

et ces la méthode getConnection qui me pose probleme. J'imaginais faire un classe avec un variable static de type DataSource et la méthode getConnection qui me renverai la connection de la datasource. Mais la DataSource comment la remplir au départ ????

Désolé si je m'entete mais j'ai vraiment peur de m'y perdre si je rentre dans Spring

Bonjour

Lorsque tu developpe une appli J2EE tu ne doit pas tenir compte du serveur. Le pooling de connection jdbc doit être fourni par le serveur d'appli et accessible via jndi, sous la forme d'un DataSource.

Je te conseille de lire http://christophej.developpez.com/tu...ee/pooltomcat/
ou tu trouvera comment configurer le pool dans jndi et un exemple de recuperation du data source dans la methode init de la servlet.
Tu peut cacher au DAO le DataSource dans un singleton qui ne va faire le lookup jndi qu'une seule fois.
De ce fait , tu est indépendant du serveur d'appli, et ta couche DAO ne dépends des servlets

Cordialement

Merci willy je vais opter pour cette solution

Citation:

---

Envoyé par willy78

Tu peut cacher au DAO le DataSource dans un singleton qui ne va faire le lookup jndi qu'une seule fois.

---

Le problème ici c'est que lors des tests, tu n'as pas accès à JNDI, c'est pour ca qu'il est plus propre d'injecter la dépendance vers le datasource (qui peut venir de JNDI ou d'un pool personnel créé pour le besoin des tests unitaires).
Cette injection peut se faire avec Spring, mais il est tout à fait possible d'imaginer une gestion manuelle lors de l'initialisation mais ca veut dire 2 configurations manuelles différentes (une pour l'appli et une complexe pour les tests qui doit tenir compte de tous les cas à tester).

Citation:

---

Envoyé par dlemoing

Le problème ici c'est que lors des tests, tu n'as pas accès à JNDI, c'est pour ca qu'il est plus propre d'injecter la dépendance vers le datasource (qui peut venir de JNDI ou d'un pool personnel créé pour le besoin des tests unitaires).

---

La j'ai pas tout compris :oops:

C'est très simple.

Citation:

---

Envoyé par willy78

Tu peut cacher au DAO le DataSource dans un singleton qui ne va faire le lookup jndi qu'une seule fois

---

Qu'est ce que ca veut dire ?
1- le DAO utilise une instance configurée pour aller chercher un DataSource dans JNDI, ce qui suppose qu'on se trouve dans un serveur d'application. Ce n'est malheureusement pas le cas quand on lance des tests unitaires (ils sont fait en dehors du serveur d'appli)
2- ce qu'il est préférable de faire c'est d'ajouter une méthode setDatasource(...) dans ton DAO pour laisser ton infrastructure injecter la dépendance dans le DAO
3- DataSource étant une interface, on faisant comme ca, on peut choisir d'injecter différentes implémentations. Par exemple, une implémentation fournie par le conteneur (datasource venant de JNDI) ou une autre créée pour le besoin des tests.

Au final, l'architecture obtenue peut être testée unitairement sans se soucier de l'environnement (tests unitaires, serveur d'appli)

Ah merci beaucoups de l'explication ca devient bcp plus clair.

Juste une question moi mon appli je la developpe sous tomcat et elle restera sous tomcat, la je peux utiliser la datasource de tomcat ?

D'ailleur est qu'une datasource est nescessaire un pool de connection ? Car dans tomcat quand je la récupere via le JNDI ca se comporte apparement comme un pool de connection.

Je te conseille de lire la javadoc. Les 3 types d'implémentations possibles sont détaillées.

Merci de ta patience

Bonjour

Citation:

---

Le problème ici c'est que lors des tests, tu n'as pas accès à JNDI, c'est pour ca qu'il est plus propre d'injecter la dépendance vers le datasource (qui peut venir de JNDI ou d'un pool personnel créé pour le besoin des tests unitaires).

---

Je suis d'accord, l'injection est plus propre, le couplage entre les classes plus faible.
Pour info, il est aussi possible de faire des tests avec junit et jndi (fixture jndi) http://www.javaranch.com/codebarn.jsp

Cordialement

Brousaille reprend l'exemple de serge tahé, fais le point par point. Prend le temps et pose nous des questions si tu ne comprend pas. Assimile ce tutorial c'est le meilleur conseille que je puisse te donné. Car en dehors de seulement spring il t'apportera des notions indispensables. Alors prend quelques heures pour le faire et n'hsites pas a nous demander de l'aide.
Apres tout sera clair et limpide si si