IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Spring Java Discussion :

Quel serveur d'application pour application de gestion JEE


Sujet :

Spring Java

  1. #21
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2006
    Messages : 178
    Points : 274
    Points
    274
    Par défaut
    Pour Spring je ne vais pas le défendre car je partage ton avis. Pourtant j'ai été un early adopter comme on dit, mais au final ca devient vite complexe et avec des dépendances de partout qui sont très contraignantes.
    Pour JavaEE (car tu oublies un peu vite TomEE, GlassFish, Paraya, WAS et Weblogic) c'est une norme (JSR) donc ca évoue moin svite.
    Enfin tes reproches sur JBoss AS 7 et le temps de sortie de WildFly oublient un peu vite qu'on passe de JavaEE 6 à JavaEE7. Et c'est sans compter les utilisateurs qui se plaignent des sorties trop fréquentes de WildFly depuis.

  2. #22
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    Dans le courant de l'année 2012, JBoss qui n'avait rien d'autre à faire en a profité pour se suicider (comme ça, ça lui passait par la tête...),
    Les développeurs ne vivent pas que d'amour et d'eau fraiche Cette action de créer EAP répondait en fait à une demande de certains utilisateurs qui voulaient un package mieux garanti quitte à le payer, ce qui tombe bien parce que de l'autre côté, les développeurs demandent des sous pour coder. Ce n'était dont pas un suicide ou une folie, c'était une opportunité d'avoir du retour sur investissement sur le serveur d'application, permettant de continuer un dévéloppement pérenne du serveur (OSS aussi bien que commercial).

    en devenant strictement payant
    C'est pas vraiment vrai ça. Il y a toujours eu et il y aura toujours une version OSS du serveur. Après, il y a eu un moment où ce n'était pas la priorité des principaux développeurs de l'avancer, mais il n'est pas devenu payant pour autant.

    Mais quel gâchis et quelle perte de temps !
    Si EAP n'était pas là pour ramener des $$$, il n'y aurait peut-être jamais eu de resources pour développer WildFly...

    Il est pas toujours acquis que ce que l'on fournira dans son ear remplacera réellement les modules équivalents installés sur JBoss.
    Le comportement est spécifié (par la spec Java EE je crois): les modules du serveur d'app prennent le dessus. Mais il y a moyen de configurer ça: https://docs.jboss.org/author/displa...ing+in+WildFly "Prevent automatic dependencies from being added".

    3) Le CDI. Va pour @Inject et @Named. Mais @Qualifier, @Alternative etc. qui connaît, qui comprend ? Comment s'y sont-ils pris pour expliquer cela aussi mal ? Vous avez déjà réussi à parcourir toute une doc sur le CDI dans JEE en entier, vous ? Moi pas. C'est tellement étrange et tarabiscoté les exemples d'emploi que je n'ai jamais réussi à m'y projeter vraiment. Là encore : c'est sûrement puissant, mais pas très intelligible.
    Là-dessus, je suis d'accord. Après, c'est comme tous les frameworks: les cas de base sont simples car ils résolvent les problèmes simples; mais ça se complique au fur et à mesure que le problème se complique (malheureusement beaucoup de problèmes compliqués n'ont pas de solution simple). Au final, le @Qualifier et compagnie, mieux vaut ne pas s'y intéresser tant qu'on n'en a pas besoin et ne pas chercher à introduire leur complexité pour résoudre des problèmes simples.
    Bref, CDI c'est facile jusqu'au moment où on veut faire des trucs compliqués.

    Je suis sévère avec les deux systèmes. Le problème de fond, c'est qu'un nouveau venu avec zéro à deux années d'expérience il doit pouvoir bosser quelque-part.
    La je pense que le problème est plus dans la formation: quand on adopte un framework structurant, il est important de former les nouveaux venus. Soit ça doit se faire à l'école (mais vu la myriade de frameworks c'est pas évident d'en enseigner juste un et surtout le meilleur pour la carrière de l'étudiant), soit il faut que les entreprises prennent leurs responsabilités en laissant l'opportunité aux développeurs de se former avant d'agir. Payer des bouquins, laisser du temps libre pour apprendre une techno, payer des formations... il y a des manières de faire.
    La on parle de Java EE, mais l'exemple est tout aussi vrai sur PHP avev Symfony ou Zend, ou JS avec Angular. Les frameworks ça peut devenir compliqué, ça demande plus que de savoir faire un Hello World.
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  3. #23
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    De mon point de vue, surtout sur ce forum, je vois des gens se lancer dans JavaEE sans comprendre les base du Java, et ça, c'est suicidaire. Difficile d'expliquer JavaEE à un débutant et pour cause, ça ne vise pas les débutants dans le language. Toutes ces api (CDI, EJB, JMS, ...) ça nécessite au préalable la maitrise de certaines notions: les transaction, les classloaders, les annotations, les generics, les interfaces, le multithread, ... Je pense qu'il est inutile de se lancer dans du javaEE si on n'a pas au moins 6 mois d'expérience temps plein en java.

    Arquillian est difficile à configurer oui, sur des projets complexes. Si ton projet c'est du maven et que t'as suivi les instructions de maven pour installer et configurer tout, utiliser arquillian se résume à mettre le plugin dans ton pom.xml. De plus tu ne le configure qu'un seule fois, pour toute la vie du projet. Passer 2~4 jours à le configurer sur un vieux projet qui n'a jamais été testé, c'est donc tout à fait acceptable vu le gain. N'oublions pas non plus qu'arquillian lance des tests d'intégration, ça nécessite pas mal d'infrastructure: un serveur EE, des bases de données similaires à la prod, ... Rappelons aussi qu'en général tu peux tester tes EJB sans serveur: ce ne sont que des classe java, il suffit de les instancier, de les initialiser dans le test et d'appeler les méthodes. Pareil pour les beans CDI et les MDB.

    Pour la doc, je trouve au contraire qu'oracle fait de gros efforts pour la rendre plus lisible depuis quelques version, et la doc CDI est bien claire http://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html Pareillement, les Qualifier sont très bien expliqués http://docs.oracle.com/javaee/6/tuto...oc/gjbck.html: c'est une annotation custom que tu met sur un bean pour discriminer en cas d'ambiguité. Par contre si t'essaie d'apprendre en lisant les 800 pages dela Spec, ça, c'est indigeste, mais c'est destiné aux créateurs de serveur java ou à celui qui veux une précision sur un point obscur


    Pour JBoss: ça a toujours été la galère pour remplacer les composants standard mais, ces composants faisant partie de la spec JavaEE, si tu fais une application javaEE, tu n'a pas besoin de remplacer ces composants. C'est encore une fois une opération que tu as rarement besoin de faire. J'ai ici de grosse application javaEE avec du jboss 4 et du wildfly 9: on n'a pas besoin de le faire, on utilise au maximum le standard.

  4. #24
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    605
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 605
    Points : 670
    Points
    670
    Par défaut
    @Mickael_istria, sur le sujet des débutants :
    Sitôt l'étudiant sorti de l'école, la première entreprise venue lui proposera un sujet JEE (qu'il soit EJB ou Spring) parce qu'il n'y en a pas d'autres. Ou alors très exceptionnellement.

    Le jeune il arrive avec son Bac+2 Java, zéro année d'expérience, il devrait trouver un job. Or, à l'inverse de ce qui se passe pour les offres PHP où de nombreuses sont destinées aux débutants, c'est une inflation des années d'expérience réclamées que l'on observe dans celles Java, et cette expérience qui est demandée, elle est demandée sur le framework cible. Et c'est là qu'il y a une erreur.

    Pourquoi ?
    1) Le DSI a ouvert un poste parce que dans 80% des cas, la MOA ou la direction lui a demandé de faire évoluer ou de créer de nouveaux traitements métiers.
    Ce sont des services de l'entreprise qui ont besoin de :
    - nouvelles pages web de saisie de configurations d'articles vendus,
    - nouveaux batchs de traitement de commandes,
    - contrôles d'ordre de fabrication,
    - états analytiques comptables spécifiques.
    - etc.

    et le DSI ne peut de toutes façons que s'exprimer en termes métiers vers sa direction qui ne comprendrait pas d'autres discussions que celles sur l'avancée des développements dans les processus métiers de l'entreprise et les règles de gestions choisies ici ou là.

    2) Le rôle d'un framework est de faciliter le développement. Pour simplifier, un bon framework devrait me permettre de me limiter à faire mes implémentations dans les couches objets métiers, service, web et coordination / contrôleur, sans rien me demander de plus.

    Or que se passe t-il ? On demande à chaque développeur de savoir faire le développement métier (ce qui est normal), ainsi que d'avoir la très bonne compréhension du framework dans lequel il s'inscrit et savoir assurer sa configuration. Choses qui ne s'acquièrent (si on si intéresse) qu'après un bon nombre d'années.
    Alors que ça n'a pas de nécessité.

    Dans la mesure où avec le temps, les configurations se font en nombre de plus en plus limité (on en fait beaucoup au début, et puis après, elles y sont quasiment toutes), c'est à l'architecte JEE (ou au tech leader) de l'entreprise de s'en occuper et dans l'absolu je trouve légitime qu'il ait ces rôles :
    - s'il y a une complexité dans le framework, mettre en place les classes d'entreprise parentes ou autres dispositifs qui permettront de passer l'obstacle le plus facilement possible.
    - s'il y a un standard ou une bonne pratique à faire connaître et qu'il pense qu'il n'est pas acquis que tous la connaissent, il ne doit pas se formaliser de devoir l'expliquer, fût-ce souvent.
    - il est le seul qui intervient dans les applicationContext.xml et standalone.xml. S'il s'aperçoit que ça lui est pénible de devoir intervenir trois fois par semaine sur l'applicationContext.xml au nom de l'un ou l'autre développeur, il sera le plus concerné pour trouver comment limiter ces désirs sans fin de configurations de Spring.
    - il gère les évolutions de versions de composants JEE et API.

    En un mot, l'architecte JEE doit rendre le framework invisible. C'est son job. Et à mon sens, il n'en a pas d'autres.
    En exagérant et en poussant à la limite, je pourrais écrire mes méthodes de service dans un @Named, et ne pas savoir si c'est un @Service de Spring ou un @Stateless d'un serveur d'application que j'ai derrière ! Je n'ai pas besoin de le savoir.

    Et c'est ainsi que l'on peut prendre des débutants connaissant seulement :
    - un framework web : JSF, Angular, Struts, GWT...
    - JPA 2 (même pas Hibernate : l'architecte JEE doit le dissimuler ; même pas les mappings entités <-> objets métiers : c'est aussi à l'architecte JEE de les dissimuler, à lui d'être un pro de Dozer et autres ; et même MongoDB c'est du JPA quand on s'y prend bien : là aussi l'architecte il doit faire que les développeurs arrivent doucement à MongoDB et non pas demander à ce qu'ils le connaissent déjà).

    et c'est tout ! Et encore : moi, je n'ai besoin que d'un débutant connaissant le framework web : JPA avec le temps, je l'y forme. D'autant que normalement, si le taf il est bien fait : il y a des DAO depuis longtemps pour esquiver JPA, et je n'ai même pas besoin qu'ils le connaissent.
    Les transactions, le débutant, il n'a pas besoin de connaître (on se démerde pour que tout passe en REQUIRED par défaut et on règle les adaptations exceptionnelles derrière son dos, s'il le faut). On lui expliquera les choses avec le temps.
    Les objets métiers on peut lui apprendre comment les faire bien en live.
    Les batchs on lui apprend le principe en ayant simplifié le mécanisme des batchs du framework pour les rendre utilisables avant.

    Le débutant il doit se concentrer sur le métier. Sur rien d'autre. S'il s'occupe d'autre chose, c'est que l'architecte JEE / Tech leader il a mal fait son boulot.
    On a besoin que d'un seul architecte pour assurer tout cela avec une bonne cohérence. Mais il faut qu'il le fasse. En entretien, il est fréquent que l'architecte JEE ait le toupet de poser des questions aux candidats pour savoir s'ils savent faire... ce qui est son job à lui ! Et je suis sidéré et assez exaspéré par cela.

    Une entreprise où l'architecte JEE / tech-leader bosse bien est libre parce qu'elle peut avoir plein de développeurs de zéro à dix ans d'expérience (avec un bagage fait de : web + JPA seulement) qui agissent strictement sur des problèmes métiers de plus en plus complexes,
    une entreprise où l'architecte JEE est un gargarisateur, il parle et critique, mais répartit le boulot parmi les développeurs et en fin de compte, ceux-là ne se concentrent plus sur leur tâches métiers mais s'interrompent quotidiennement sur des problématiques de configurations et d'architecture technique, et pour lesquels il faut une liste à rallonge de compétences et un minimum d'années d'expérience.

    Donc, pour moi aujourd'hui, le problème en entreprise vient de l'architecte JEE. Une fonction qui est bien trop vite accordée à l'unique personne qui doit l'avoir, sans prendre le temps de vérifier si elle voudra bien libérer l'équipe de développement des contingences du serveur d'application choisi.


    @tchize, sur le remplacement des composants standards de JBoss
    C'est vrai ce que tu écris. Il faudrait se limiter à l'emploi des composants standards de JBoss.
    Mais dans 100 à 150% des entreprises qui utilisent JBoss depuis plus cinq ans, tout redéfinit tout et l'on est souvent aux prises avec des jar hells à la façon des DLL hells de l'époque C++ de Windows.

  5. #25
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    Il est assez aisé de prendre un débutant et de le faire entrer sur un projet JBoss, et beaucoup moins simple de le faire entrer sur un projet Spring
    JBoss et Spring sont deux choses complètement différents, l'un est un serveur d'application qui respecte les spécifications et te permet de développer une application en standard Java EE, l'autre (Spring) est un framework à part. Cependant il y a autant d'apprentissage avec les commandes JBoss + les spécifications standard Java EE que pour faire du Spring (qui lui utilise de manière transparent Tomcat par défaut).

    Citation Envoyé par grunt2000 Voir le message
    Impossible de déclarer une simple servlet qui n'adhère pas au modèle MVC de Spring sans se plonger longtemps dans la doc.
    Oui, mais c'est le cas de tout les produits dont tu souhaites étendre les fonctionnalités de base (et je ne pense pas seulement au domaine de l'informatique). Pour le cas de Spring, c'est simple : t'es Spring ou t'es pas Spring (ça fait un peu "tu l'aimes ou tu la quitte" désolé ce n'était pas volontaire ).

    Citation Envoyé par grunt2000 Voir le message
    Spring MVC doit être la pire plaie de toute l'histoire de l'humanité,
    Ben en fait, pas tant que ça, tu reprends la spec JAX-RS et tu changes les annotations (j'ai rédigé un article là-dessus), et pour être franc venant du standard, j'ai eu beaucoup plus de facilité à mettre en place une application Spring MVC que JAX-RS avec l'implémentation Jersey dans un servlet container Tomcat. De plus Spring MVC gère implictement le mapping des objets (avec Jackson).

    Citation Envoyé par grunt2000 Voir le message
    3) Le CDI. Va pour @Inject et @Named. Mais @Qualifier, @Alternative etc. qui connaît, qui comprend ? Comment s'y sont-ils pris pour expliquer cela aussi mal ? Vous avez déjà réussi à parcourir toute une doc sur le CDI dans JEE en entier, vous ? Moi pas. C'est tellement étrange et tarabiscoté les exemples d'emploi que je n'ai jamais réussi à m'y projeter vraiment. Là encore : c'est sûrement puissant, mais pas très intelligible.
    => C'est ce qui arrive quand on reprend un concept existant (Spring IoC) et qu'on change les noms pour éviter le plagiat.

    Citation Envoyé par grunt2000 Voir le message
    avec le temps, je l'y forme.
    Vous êtes bien bon messire !. Sauf qu'on est loin de la réalité du marché .


    Bon perso j'ai commencé avec le standard Java EE et ça reste pour la référence en terme de développement web en Java, cependant Spring n'est pas si mauvais. J'ai étudié Spring 3 durant mes études, époque à laquelle on utilisait encore le fichier applicationContext.xml pour configurer les beans... cependant avec Spring 4 (et donc Spring Boot), tout a été simplifié à un niveau monumentale :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    import org.springframework.boot.SpringApplication;
    import org.springframework.boot.autoconfigure.SpringBootApplication;
    import org.springframework.context.ApplicationContext;
     
    @SpringBootApplication
    public class Application {
     
        public static void main(String[] args) {
            ApplicationContext ctx = SpringApplication.run(Application.class, args);
        }
     
    }
    Avantage : plus de XML, tout est full-annotation, pas de problème lié au cache du container lorsqu'on modifie juste un passage du ficher XML (cf: web.xml pour Java EE est une plaie aussi) vu qu'il n'y a plus de XML.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  6. #26
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2006
    Messages : 178
    Points : 274
    Points
    274
    Par défaut
    Ben en fait, pas tant que ça, tu reprends la spec JAX-RS et tu changes les annotations (j'ai rédigé un article là-dessus), et pour être franc venant du standard, j'ai eu beaucoup plus de facilité à mettre en place une application Spring MVC que JAX-RS avec l'implémentation Jersey dans un servlet container Tomcat. De plus Spring MVC gère implictement le mapping des objets (avec Jackson).
    JAXRS le fait aussi : jackson est present dans Resteasy par exemple


    => C'est ce qui arrive quand on reprend un concept existant (Spring IoC) et qu'on change les noms pour éviter le plagiat.
    Mince j'ai toujours cru que les gens de Spring faisaient partie de la JSR ;o) Java EE standardise sur des solutions éprouvées (comme JPA basé sur Hinernate JDO et Toplink), CDI s'est standardisé en partie sur Spring.

    web.xml c'est aussi has been que la configuration Spring en XML. Bientot on va ressortir les .ser des EJB 1.

    @Grunt2000 : pour JBOss sur 5 ans tu peux prendre l'option EAP (payante) mais qui te garantie les mises à jour retro compatibles. Sinon avec jboss-modules tu peux justement avoir plusieurs versions de tes jars selon tes applications.

  7. #27
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    JAXRS le fait aussi : jackson est present dans Resteasy par exemple
    L'implémentation de référence de JAX-RS (qui est Jersey) ne le fait pas, le fait d'utiliser des objets en paramètre de méthode avec une sérialisation implicite en JSON n'est pas un standard JAX-RS. Il est cependant possible d'utiliser des objets personnalisés si ces derniers respectent certaines condition définies dans : documentation §3.2 | Example 3.9, mais il n'y a pas de sérialisation directe en JSON (avec une implémentation Jackson ou autre) comme pour Spring MVC.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  8. #28
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2006
    Messages
    178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2006
    Messages : 178
    Points : 274
    Points
    274
    Par défaut
    Tu avais un provider dès la version 1 de Jersey.
    Tu l'as via JAXB donc standard de Java EE: https://jersey.java.net/documentatio...a.html#d0e7963
    Tu dois pouvoir écrire ton prope code sur Json-p. Sans compter les autres méthodes non-standard mais qui en réalité fonctionneront avec les autres serveurs d'application.
    Bref je trouve cela un 'faux' problème.

    Spring et JavaEE apportent une solution très proche aux mêmes problèmes : génération coté serveur, http, gestion de la transaction, mapping objet-relationnel, mom etc. Et ca c'est valable dans toutes les applications à des degrés divers. Après
    Chaque pile est composable à volonté : soit en ajoutant des éléments (approche Spring) soit en en retirant (approche Java EE avec les profiles notamment d'ailleurs on notera aussi que tous les serveurs Java EE sont modulaires) mais au final c'est quasiment la même chose et l'approche light container de Spring est aussi lourde que Java EE de nos jours.

  9. #29
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    605
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 605
    Points : 670
    Points
    670
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    JBoss et Spring sont deux choses complètement différents, l'un est un serveur d'application qui respecte les spécifications et te permet de développer une application en standard Java EE, l'autre (Spring) est un framework à part.
    [...]
    Pour le cas de Spring, c'est simple : t'es Spring ou t'es pas Spring (ça fait un peu "tu l'aimes ou tu la quitte" désolé ce n'était pas volontaire ).
    Comment expliquer ma vision des choses ?
    Le serveur d'application ou Spring, il y a un temps pour l'installer et le configurer. Et puis, il doit s'effacer.

    À un moment, la MOA, la direction de l'entreprise, donnent des directives pour que des travaux métiers soient accomplis : des processus, des IHM ou des sites web qu'elles veulent voir mis en place. À ce moment, leur évoquer Spring ou JBoss suscitera leur incompréhension : ce n'est pas le sujet. Le sujet c'est pas quel serveur d'application ou framework a t-on, mais : "Qu'est-ce qu'on fait avec ?".
    Des développements informatiques qui se déroulent sur quatre ou huit ans par exemple, si au bout de six mois tu es encore entrain de parler aux gens de JBoss ou Spring, il y a un problème. Les datasources, la sécurité, la définition des files de messages, ça devrait soit être fini, soit ne plus réclamer que des interventions rares et ponctuelles. Si la prégnance du framework demeure, c'est parfois un standalone.xml ou un applicationContext.xml mal finalisé, mais plus souvent des classes qui réclament lors de leur écriture d'exécuter des instructions du framework directement, alors que ces instructions spécifiques là auraient dû être logées dans des classes de base, abstraites ou des modules "système" et ne plus être visibles depuis longtemps.

    Après six mois de développement, le sujet ce n'est plus le framework, c'est le boulot métier qu'on fait pour ceux qui nous l'ont demandé. Tu ne peux plus répondre ni à ta direction, ni à tes développeurs : "Il faut être Spring ou pas Spring", parce que tu devrais être passé à autre-chose, à un autre stade de tes réalisations et ne laisser la maintenance et l'évolution de ton framework / serveur d'application au seul Architecte JEE qui en est responsable, et laisser tous tes développeurs strictement sur les sujets métiers.

    Et ce que tu écris est révélateur, à mon sens, du problème qu'il y a avec le framework Spring.
    C'est que ceux qui le choisissent consacrent trop de temps à faire "du Spring" : à le paramétrer, à en débattre, à l'accroitre, à le transformer, à tourner autour au lieu de s'occuper du sujet principal qui intéresse vraiment l'entreprise : les applications métiers. Elles, ces applications métiers, ne dépendent que :
    - De sites web ou IHM lourdes
    - De DAO ou autre système pur JPA
    - De files d'attentes
    - D'un paramétrage de sécurité.

    Et ça, c'est parfaitement indépendant (à part le dernier point), du framework / serveur d'application qui se trouve derrière ou en tout cas, peut se considérer sans réclamer de savoir auparavant lequel il sera.
    À mon avis, c'est le sens des rapprochements en cours via les JSR : @Inject, @Named qui remplacent petit à petit @Service, @Stateless, @Component, @EJB.... afin d'équarrir cette terminologie doublonne.

    Si au bout de six mois de dev on est encore entrain de penser Spring ou JBoss, c'est qu'on a loupé sa mise en place de Spring ou de JBoss, à mon sens.
    Si les développeurs doivent faire du Spring ou du JBoss au lieu de faire des DAO, des objets métiers, des services et des pages web, c'est que quelque-chose n'a pas été fini dans l'installation initiale du JBoss ou du Spring.

  10. #30
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Je ne vois pas trop où tu veux en venir. Tu dis qu'il faut se concentrer sur le métier au lieu de la technique ? (cf: DAO). Si tu fais de l'informatique, tu dois à la fois maitriser la technique et le métier ainsi que les problèmes et contraintes liés à ces deux concepts, l'un ne va pas sans l'autre, car si tu ne vis que pour la technique tu passeras pour un gros geek, si tu fais mine de ne te focaliser que sur le métier parce que tu n'aimes pas toucher à du code tu passeras pour - excuse moi du terme - un gros branleur. Finalement les JSR ou Spring ne sont qu'un reflet pour apporter une solution aux problèmes techniques existants.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  11. #31
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    605
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 605
    Points : 670
    Points
    670
    Par défaut
    Tu y vas un peu fort !
    À un moment donné, il faut tout de même réaliser quelque-chose avec ce que l'on a. Un framework ou un serveur d'application sont un socle pour bâtir quelque-chose dessus, et c'est cette chose bâtie dessus qui a de l'importance pour l'entreprise.
    Oublier cela, c'est quand même risquer de se dévoyer.

    si tu fais mine de ne te focaliser que sur le métier parce que tu n'aimes pas toucher à du code
    Au contraire : c'est quand tu t'occupes du métier que tu fais du code !
    Si tu produis des jeux d'écritures comptables d'après des commandes clients, il faut bien mettre le code Java derrière pour qu'elles se fassent. Et le code à écrire, à l'inverse de ce que tu penses, est plus volumineux (normalement) que tout ce que tu auras eu à écrire de Java spécifique à Spring ou JBoss.

  12. #32
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    te focaliser que sur le métier parce que tu n'aimes pas toucher à du code tu passeras pour - excuse moi du terme - un gros branleur.
    un architecte

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Quel langage de programmation pour application LINUX
    Par The schild dans le forum Linux
    Réponses: 8
    Dernier message: 21/08/2015, 12h13
  2. Serveur Java EE pour application web et application web mobile
    Par DavidleVrai dans le forum Développement Web en Java
    Réponses: 2
    Dernier message: 21/01/2015, 11h11
  3. Cherche programmeur pour application pour l'astronomie
    Par astroghost13 dans le forum ALM
    Réponses: 1
    Dernier message: 18/08/2010, 15h37
  4. quel approche de developpement pour application evolutive
    Par benben02 dans le forum Général Java
    Réponses: 1
    Dernier message: 06/12/2009, 16h14
  5. Réponses: 1
    Dernier message: 05/07/2007, 16h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo