Spring par-ci, Spring par là.

Bonjour à tous,

Ici au travail, nous somme sur l'analyse et l'étude d'un projet de ressource humaines (gestion du workflow industrialisé allant de l'inscription d'un nouveau membre engagé jusqu'a la fin de son contrat avec la société), jusqu'ici rien de bien méchant vous me direz...

Le problème est que, mon collègue qui a la charge du projet, s'est décidé à aller de l'avant en utilisant les technologies nouvelles comme : hibernate, spring, gwt ou extjs design pattern(MVC et autres) blablabla

Il se posaient plusieurs question quand à ces technos.

N'y connaissant rien il s'est lancé dans la lecture de livres traitant de ceux-ci il apprécia bien toute les technos mais resta sceptique sur Spring ne trouvant aucun avantage à l'utiliser. Le livre qu'il a passé en revu pour étudier Spring est "Spring Recipes (2.5) | A problem/solution aproach" des éditions Apress quelquechose à ne pas négliger quand même.

Sans vouloir dire du mal, mon collègue à 15 ans d'experience dans le développement, il déteste tout ce qui est diagrammisation (UML et autre) je me demande d'ailleur comment il a pu tenir sans tout cela (peut-être à cause de son coté autiste déterminé, qui sait) et en java en plus mais bon il ne fait que du jsp lol donc allez savoir, malheureusement pour lui, il a aussi un esprit très technique trop même.

Il a parcouru le livre sur spring et n'a pas apprécié et il n'a trouvé quasi aucune utilité à utiliser Spring pour le projet de ressource humaines, étant confiant de la communeauté et de cette fameuse image de marque qu'apporte Spring j'ai moi même décidé de parcourir le livre car je me suis dit qu'il n'a peut-être pas compris grand chose parce qu'il y a trop de concepts à comprendre en UML et voici où j'en suis :

J'ai bien saisi le concept IOC et DI d'accord on a tous compris cela (je crois lol, c'est peut être moi qui me trompe dans la compréhension hihi)

J'en suis au chapitre 3 du livre : "Beans configuration"

Et l'idée de configurer des objets je l'a trouve, moi aussi, un peu débile dans le sens où je ne voit pas où est l'utilité de configurer des objets pour travailler avec il se peut que comme je ne suis qu'au chapitre 3 il me faut encore parcourir le livre et que je trouverai la réponse plus loin qui sait.

Et donc, mes question sont :

A quoi sert Spring?

Quels sont les raisons qui nous pousseraient à l'utiliser?

Quel est le gain qu'apporte vraiment Spring au vu de ce qu'il contien (MVC, security, et j'en passe) sur le court et long terme...?

Serait-il utile d'utiliser Spring pour un tel projet qui se verrai sérieusement grandir au fil des années...?

Veuillez m'excuser pour la longueur de mon message mais il faut bien que je place le décor pour en connaitre la profondeur de la difficulté...

Merci à tout ceux qui auraient prit la peine de lire le message jusqu'au bout ainsi qu'a ceux qui auront répondu.

Bien à vous

salut,

si tu avais compris les conceptes derrière IOC et DI tu aurais compris ou est la force de spring dans tous ça:mouarf:
spring est un framework de développement d'application entreprises de toutes les tailles et toutes les complexités. Il présente différentes facilités et de gain de ton dans le dévelppement tel que gestion des transactions, securité, accès aux couches persistantes et j'en passe.
il promet le découplage entre les différentes couches d'une applications....

Peut-être, et même sûrement, mais encore voilà...

Ma méthode de travailler en générale se résume à

DB -> DAL(DAO) -> [MVC]

IOC c'est intéressant DI aussi mais pour moi personellement je ne vois pas en quoi Spring me serai utile, note aussi que je bosse avec les EJB de manière générale mais plus depuis un sérieux moment, peut-être que c'est normale que je saisi pas Spring, non...?

En plus la question principale que je me pose et que j'ai oublié d'énoncé c'est que je vois pas comment, par exemple, faire pour faire transiter mes données depuis ma BD avec spring vers ma View et quoi, mon ORM va devoir créer des xml beans à tout bout de champs pour les refiler à ma View...?

je trouve pas ça très logique... mais encore une fois je ne suis qu'au 3e chap donc il se peut que c'est normale quoi et je suis toujours dans la lecture

vous en pensez quoi?

je partage le même scepticisme :oops:

Citation:

---

Envoyé par programaniac

Peut-être, et même sûrement, mais encore voilà...

Ma méthode de travailler en générale se résume à

DB -> DAL(DAO) -> [MVC]

IOC c'est intéressant DI aussi mais pour moi personellement je ne vois pas en quoi Spring me serai utile, note aussi que je bosse avec les EJB de manière générale mais plus depuis un sérieux moment, peut-être que c'est normale que je saisi pas Spring, non...?

En plus la question principale que je me pose et que j'ai oublié d'énoncé c'est que je vois pas comment, par exemple, faire pour faire transiter mes données depuis ma BD avec spring vers ma View et quoi, mon ORM va devoir créer des xml beans à tout bout de champs pour les refiler à ma View...?

je trouve pas ça très logique... mais encore une fois je ne suis qu'au 3e chap donc il se peut que c'est normale quoi et je suis toujours dans la lecture

vous en pensez quoi?

---

il faut comprendre que IOC est le concept général et que DI est juste une implementation, si tu as travaillé avec les ejb, je pense que tu connais le pattern service locator qui est aussi une implementation de IOC.
pour le model mvc c'est spring qui s'en occupe dans le sens ou tu n'as pas t'inquéter du "glue code" qui te permettras de lier tes différentes couches pour les données tu fais tes dao normalement. qui feront "transiter" les données du model aux services et dans ton controlleur tu fais appel à ses services

ce lien explique amplement le concept de ioc et l'origine du mot di
http://martinfowler.com/articles/injection.html

Exactement la même chose que dit le livre en plus compliqué... Au final on en revient à configurer les objets au travers d'XML mais quel est le réel avantage/gain...?

C'est pas pour troller, mais, j'ai plus l'impression que c'est un framework utilisé pour favoriser certains plus que d'autres lol, vous voyez ce que je veux dire...? (les plus pervers répondront négativement lol)

Nan, plus sérieusement, je pars en training une semaine pour en apprendre plus sur spring j'aurai peut-être une meilleure idée là dessus à mon retour, qui sait...

c'est une tres bonne Glue-code, mais c'est aussi plus que ca.

Les differents sous projets de Spring peuvent amener beaucoup:

Spring-mvc est probablement le meilleur framework MVC actuellement
Spring security est excellent pour gerer des problematiques d'acces complexes.
Spring-WS est pas mal du tout
etc etc..


et enfin, c'est un framework connu par beaucoup, ce qui permet de staffer un projet assez facilement.

J'espère sincèrement...

Bref l'avenir nous le dira.

Je vous donne des feedbacks prochainement les gards :)

Salut,

Perso, entre utiliser un serveur d'appli ultra-lourd en conf, souvent au démarrage et utiliser la combo Maven/Spring/Tomcat, il n'y a pas photo.

Les deux font la même chose, sauf que l'un est truffé de choses inutiles dont tu ne connais même pas les tenants et aboutissants, et l'autre collera à tes besoins sans en faire plus, avec des briques logicielles que tu connais, tout ça pour un démarrage de serveur de 6 secondes chrono en main...

Qui plus est, tomcat est bien plus simple à config pour des tests d'intégration (selenium/fitnesse) contrairement aux autres appservers.

tcharl

Je trouve que je développe plus vite en utilisant ce genre de plate forme. Puis je trouve ça plus élégant et clair mais ça, ça dépend de tout un chacun...

Bonjour,

Je répondrais peut-être un peu à coté de la plaque en ayant qu'une expérience de quelques années. (Loin des 15 ans d'expérience cités ci-dessus).

Je pense que la problématique de Spring est à prendre d'un point de vue un peu plus haut que simplement l'apport technique via des procédés de type IOC, ID. Eloignons nous un peu du concept et essayons de comprendre ce que cela change au final dans l'application.

D'une part, le premier argument qui me vient en tête est l'organisation du projet. Cités plus haut, sont Maven/Hibernate et autres. Une telle foule de framework différents, nécessitent forcement une organisation du code source propre. Des normes existent pour cela. Travailler avec des concepts IOC, ID, forcent encore plus l'utilisateur à garder une structure de projet claire et propre. On a des interfaces, des implémentations et le découpe est plus net.

Deuxième argument, la souplesse. Vous choississez aujourd'hui Hibernate. C'est un choix admirable, c'est un beau projet qui a des fonctionnalités très sympa et que j'utilise moi même régulièrement. Il se peut que dans quelques temps, vous vous apperceviez que Hibernate ne convient plus à votre application. Vous décidez de franchir le cap pour aller sur du NoSql. (C'est un exemple). La programmation IOC vous a obligé à travailler avec un découpage clair, simple. Vous n'aurez donc que la partie DAO à modifier. En local, vous changer deux, trois propriétés dans les XML de configuration et vous pouvez basculer sur une implementation autre. Souplesse donc.

Troisième argument, la qualité de l'outil. Spring Source est une communauté qui est fortement active et le projet est loin d'être mort. Il continue d'avancer et de multiples briques existent. On a parlé plus haut de Spring Security, de Spring ORM ou encore de Spring Batch. Des projets qui présentent des interets pour chaque situation et qui tournent autour d'un noyau commun. Dieu sait que l'interaction entre framework peut être ardue à configurer.

Pour moi, Spring est devenu un composant essentiel pour chaque projet J2EE. Simple à utiliser, facile à configurer, (dans sa dernière version, cela se fait essentiellement via des annotations dans le code), fiable et rapide.

Bref, j'espère avoir répondu à tes interrogations mais un framework ne peut être jugé qu'une fois qu'on l'a essayé. Faites un POC, en testant différents framework. Réaliser ensuite cette même application sans Spring. La différence vous permettra de vous faire une idée sur cet outil. En tout cas, mon retour personnel est très positif. ;)