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

Java Discussion :

Java est-il un choix coûteux pour les entreprises ?


Sujet :

Java

  1. #81
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par damien.charpentier Voir le message
    la JSR 303 defini un standard pour une application en Java (de la couche presentation jusqu'au DAO). Ce n'est pas de la responsabilite de cette specification de gerer des technologies completement differentes (comme une base de donnees). Il faudrait se tourner vers des editeurs qui fournissent ce genre de support. JSF 2 supporte la Bean Validation pour verifier la bonne saisie des champs.
    Tu vois damien, c'est un peu ça le problème de l'informatique. J'ai simplement donné un exemple pour illustrer mon propos et toi (mais tu n'es pas le seul) tu me parles de détails et du fait que ce n'est pas le rôle de l'un mais de l'autre.
    Il est justement là le problème, c'est à dire l'approche globale.

    Encore une fois, prenons un exemple avec les WebServices. On, je veux dire la communauté informatique, c'est empressé de développer cet aspect alors que l'on avait déjà des trucs comme les EJBs. Pourquoi avoir dépensé beaucoup d'énergie à inventer encore une technique de communication au lieu de tenter de résoudre des problèmes plus globaux comme le lien IHM-Métier-BDD ? Encore une fois, la profusion de technos est peut être un point intéressant mais au lieu de développer 50 solutions pour résoudre la même problématique, on pourrait essayer de consolider 2 ou 3 solutions et surtout aborder des problématiques que personne ne veut aborder.

    Et vous savez que c'est là que réside la force de Microsoft = ils proposent une solution globale, outillée. Avec eux, on ne se fait pas de noeuds au cerveau et la formation des développeurs est "plus simple" car on sait ce qu'ils vont devoir utiliser.
    Pour information, je suis du monde Java et ne connait pas les technos Microsoft. Cependant, je me rend compte que la profusion nuit forcément à la clareté.

  2. #82
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par ego Voir le message
    Encore une fois, prenons un exemple avec les WebServices. On, je veux dire la communauté informatique, c'est empressé de développer cet aspect alors que l'on avait déjà des trucs comme les EJBs. Pourquoi avoir dépensé beaucoup d'énergie à inventer encore une technique de communication au lieu de tenter de résoudre des problèmes plus globaux comme le lien IHM-Métier-BDD ?
    Parce que les EJBs manquaient de souplesse pour les échanges PHP-Ruby ?

    Et vous savez que c'est là que réside la force de Microsoft = ils proposent une solution globale, outillée.
    C'est sûr que quand on peut se permettre de ne se parler qu'à soi-même, même machine, mêmes programmes, de manière générale mêmes fournisseurs, on peut faire des trucs de ce genre.
    Mais à ce niveau-là, il suffit de choisir un seul framework Java, dire merde aux autres, et prendre une solution intégrée clé-en-main qui se base sur ce framework : on obtient la même chose.
    Forcément, il ne sera pas apte à communiquer avec autre chose sans sortir de l'intégration prémâchée.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #83
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Parce que les EJBs manquaient de souplesse pour les échanges PHP-Ruby ?



    C'est sûr que quand on peut se permettre de ne se parler qu'à soi-même, même machine, mêmes programmes, de manière générale mêmes fournisseurs, on peut faire des trucs de ce genre.
    Mais à ce niveau-là, il suffit de choisir un seul framework Java, dire merde aux autres, et prendre une solution intégrée clé-en-main qui se base sur ce framework : on obtient la même chose.
    Forcément, il ne sera pas apte à communiquer avec autre chose sans sortir de l'intégration prémâchée.
    Ruby, je sais pourquoi on a investigué autre chose que les EJB, c'est simplement pour dire qu'il y a bien d'autres problèmes à résoudre que des problèmes techniques.
    Est-ce que Microsoft propose autant de frameworks pour faire des IHM que ce que l'on a dans le monde Java ?
    Ce que je pointe du doigt n'est pas la légitimité ou non de telle techno mais le fait que quand la communauté traite un problème elle n'en traite pas un autre. Et comme par hasard, on traite bien trop souvent des problématiques techniques, je ne sais pas trop pourquoi, peut être parce que c'est plus "noble" ? plus "cool" ?.
    Et même en traitant certains problèmes un peu moins techniques comme la Validation des beans, on rigole du résultat obtenu. Car valider un objet c'est :
    1- valider chaque attribut
    2- puis valider l'objet lui-même (règles inter-attributs)
    3- puis valider l'objet vis-à-vis de son environnement (règles inter-objets)
    4- bien entendu quand on récupère une grappe d'objets (DTO) on valide d'abord les données unitairement (le 1) puis les objets individuels (le 2) et le 3 ensuite.
    5- les règles doivent être déclenchées bien entendu uniquement si les données sur lesquelles la règle porte sont modifiées (comment le détecter ? SDO en parle, on peut fabriquer sa propre solution)
    6- certaines règles ne sont déclenchables qu'à un moment du cycle de vie de l'objet (création, modification, suppression)

    On en parle où de tout ça dans la JSR ?

    Même remarque sur le nombre astronomique de langages, et là Java n'y est pour rien. C'est plus "rigolo" de créer un langage que de traiter des problèmes de fond. Des têtes bien faites dépensent de l'énergie à inventer une nouvelle syntaxe alors qu'elles pourraient travailler sur autre chose.

  4. #84
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par ego Voir le message
    Ruby, je sais pourquoi on a investigué autre chose que les EJB, c'est simplement pour dire qu'il y a bien d'autres problèmes à résoudre que des problèmes techniques.
    Ça suffit. Ton exemple ne marche pas.
    Les EJBs sont un système de communication interne à Java (et tous les langages en ont au moins un fourni avec, un "canonique", et plein fourni par des tiers.) Les webservices sont interlangages et n'ont pas d'affinité particulière avec Java. C'est tout.

    Pour le reste, il y a du vrai, et en effet quand je commençais dans le métier je n'arrivais pas à choisir seul dans tout ce bazar, j'avais besoin que mes aînés décident et m'expliquent pourquoi.
    Apparemment tu prétends que sur d'autres plate-formes, c'est moins le cas. Moais. Je connais d'autres (vieux) langages, autres que Java, et ils étaient exactement pareil, bien qu'avec moins de choses pleines de hype fournies par des tiers. Après, il est vrai qu'entre-temps, les approches webservices ont explosé, et que maintenant on parle du cloud.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #85
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Le Web Service, ce n'est que de la sérialisation XML (Ou autre si on considére REST, JSON...). L'EJB n'est pas incompatible avec ça.
    La seule différence est que par nature un web service est stateless.

    Le Web service, ça reste quand même l'escroquerie architecturale de la décennie d'un point de vue architecture. C'est une vision marketing du paquet TCP. Sauf que pour beaucoup de gens; avec du XML, un XSD et les WS-i, le W3C, et du http, c'est très bien. Pire on en est même arrivé au Rest, qui est la vraie régression (dire qu'un service get ou post sur htpp; on ne peut pas dire que c'est une révolution).

    Et aujourd'hui, les architectures multi techno, je fais plus. C'est trop de temps perdu en plomberie.

    Mais c'est certain le web service hello world n'a aucune affinité avec le langage. Comme toute les technos : tant que l'exemple est trivial, la techno semble magique.

  6. #86
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Le Web service, ça reste quand même l'escroquerie architecturale de la décennie d'un point de vue architecture. C'est une vision marketing du paquet TCP. Sauf que pour beaucoup de gens; avec du XML, un XSD et les WS-i, le W3C, et du http, c'est très bien. Pire on en est même arrivé au Rest, qui est la vraie régression (dire qu'un service get ou post sur htpp; on ne peut pas dire que c'est une révolution).
    C'est brut de fonderie comme affirmation

    Le web service n'est pas une escroquerie, loin s'en faut lorsqu'on veut utiliser la même logique métier pour des clients utilisant d'autres langages que java.
    Là où je suis partiellement d'accord, c'est quand on utilise un web service écrit à partir d'un EJB dans une application java...
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #87
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Le Web Service, ce n'est que de la sérialisation XML (Ou autre si on considére REST, JSON...). L'EJB n'est pas incompatible avec ça.
    Discutable... Dans ton sens. C'est-à-dire que ce que tu dis est vaguement défendable.
    Mais à la base, les EJBs sont 100% couplés à Java, alors que les webservices sont faiblement couplés au web, et à rien d'autre. La différence de généricité et de pluralité cause de nombreux points de mésentente entre les deux.

    Pour le reste, mais oui, mais oui. Pourquoi on est pas tous restés sur le binaire, c'était très bien. D'ailleurs, on aurait parfaitement réussi à mettre toutes les technos d'accord sur une seule vue binaire des choses, et à la base c'est de cette question-là qu'on parle.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  8. #88
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    C'est brutal mais ça reste vrai.


    Si tu regardes bien, TCP est une techno simple, éprouvée, qui a aussi ses défauts de sécurité (en même temps comparée à Http et au marché du certificats...); qui permet un transport simple, uniforme, multi technologie, des messages standardisés. En plus Http n'est qu'un subside de TCP.

    Donc avant tu avais une technologie qui te permet d'avoir un serveur dans n'importe quelle technologie qui échange un message avec un client dans n'importe quelle techno (synchrone ou non), avec des options de sécurité et surtout un message normalisé et une gestion d'état (qui permet in fine de faire un dialogue fonctionnel).

    Aujourd'hui tu as une technologie qui te permet d'utiliser une autre technologie qui échange un message avec un client dans éventuellement une autre technologie à condition que les proxy puissent être partagés (et autant dire qu'il faut que ça reste simple) et sans étant, avec une sécurité assez complexe à gérer et pas si portable, le tout sans état. D'ailleurs maintenant, il y a le SML qui permet de définir le modéle. Finalement n'étant pas si pratique et interopérable, on tombe...
    Dans JSON pour finalement consommer du Web Service dans le navigateur depuis Jscript (...); voir faire du "RestFul" et lire...Un fichier text, ce qui nous raméne au point du TCP, puisque c'est de header Http. (Donc finalement....)


    Rien à dire, le web service, c'est un vrai progrés...
    (Je reconnnais, c'est sarcastique)

  9. #89
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Discutable... Dans ton sens. C'est-à-dire que ce que tu dis est vaguement défendable.
    Mais à la base, les EJBs sont 100% couplés à Java, alors que les webservices sont faiblement couplés au web, et à rien d'autre. La différence de généricité et de pluralité cause de nombreux points de mésentente entre les deux.
    Ce que je voulais dire c'est que faire des EJB et du Web Service n'a pas de rapport logique. Un EJB reste un objet java, et le web service reste juste un transport. Qu'il soit EJB ou autre, le but du jeu reste de transporter une image d'un objet.

  10. #90
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Vous voyez messieurs, c'est reparti, on essaye de prendre de la hauteur et en fait on retombe dans des débats stériles pour technophobes.

    Encore une fois, ce n'était qu'un exemple pour essayer de vous montrer que l'on aborde trop les problèmes de plomberie et pas assez les problèmes réels de conception applicative de manière globale de A à Z.

  11. #91
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Je crois qu'à trop chercher tes formules, tu en as oublié la conception globale de a à z de ton post

    En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.

    Et quand tu parles de problèmes de conception globale, c'est justement qu'il faudrait arrêter de faire de la conception avec des choix uniquement techniques réputés ouverts pour éviter de choisir et faire "comme tout le monde".

    De la même façon je trouve insupportable ceux qui ne résonnent qu'en relationnel ou en SQL.

    Il y a deux chose dangereuses en architecture logicielle :
    - Les dogmes, comme le couplage faible, les couches, les services
    - Les modes, comme les web services

  12. #92
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    957
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 957
    Points : 1 177
    Points
    1 177
    Par défaut
    Citation Envoyé par ego Voir le message
    Vous voyez messieurs, c'est reparti, on essaye de prendre de la hauteur et en fait on retombe dans des débats stériles pour technophobes.

    Encore une fois, ce n'était qu'un exemple pour essayer de vous montrer que l'on aborde trop les problèmes de plomberie et pas assez les problèmes réels de conception applicative de manière globale de A à Z.
    Je partage ton avis, c'est reparti encore une fois sur des débats hyper techniques qui s'éloignent du sujet principale. Ca n'intéresse guère que les plombiers.

    Je pense que tu voulais dire technophile.

  13. #93
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    957
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 957
    Points : 1 177
    Points
    1 177
    Par défaut
    Citation Envoyé par B.AF Voir le message
    En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.
    Pour le coup s'en est pas une

  14. #94
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.

    Ceci pour une raison très simple, c'est la même que pour obtenir la paix, la sécurité et le bonheur de tous les êtres.
    Résoudre à la fois tous les problèmes des technologies de développement, c'est probablement impossible, et au mieux c'est tellement difficile qu'on n'arrive pas vraiment à l'aborder. Ça nécessite encore beaucoup de temps d'évolution. À moins que la longévité soit significativement augmentée au cours de notre vie, nous ne verrons jamais une chose pareille.
    Ça ne signifie pas qu'on doit renoncer à essayer, seulement c'est extrêmement compliqué et ce n'est pas avec des raccourcis qu'on va décrire ses idées. D'ailleurs il y a deux questions qui sont distinctes mais interdépendantes :
    - Quel genre de technologie résoudrait les problèmes actuellement observés et prédits ?
    - Comment les faire adopter par le monde ?

    Et pour l'amour du ciel qu'on vienne pas me dire "mais moi je prétends pas que j'ai la solution, je dis juste que ça et ça c'est un problème." Les problèmes ont toujours des origines, c'est un prêté pour un rendu, tout le temps. On peut tant qu'on veut trouver qu'il aurait mieux valu pas avoir le prêté vu le rendu qu'on se paie, mais ça ça dépend des besoins. Des besoins il y en a autant que d'idées de réalisations, ils sont adressés de différentes manières, plus ou moins dans le détail, qui colleront plus ou moins avec l'idéal. Mais nier la multitude des besoins c'est chercher à stagner et le monde ne le fera pas pour vous. Personnellement je pense qu'il a bien raison.

    Ça vous va, ça, comme hauteur prise ?
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  15. #95
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Citation Envoyé par batataw Voir le message
    Je partage ton avis, c'est reparti encore une fois sur des débats hyper techniques qui s'éloignent du sujet principale. Ca n'intéresse guère que les plombiers.

    Je pense que tu voulais dire technophile.
    C'est quand même dingue de lire autant de condescendance.
    Quant à des débats hyper techniques, excuses moi mais on parle de sujet quand même très généraux et pas très complexes.
    Je pourrais te dire que si tu trouves ça hyper technique, il serait utile de ré-évaluer ta notion d'hyper

    Un débat stérile pour technophobes sur un site de développement, dire qu'il n'a pas sa place, c'est bien un tautologie.
    Enfin je concéde que le technophobe ici n'a pas vraiment sa place.

    Ou avec la plèbe plombiére ????

  16. #96
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    957
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 957
    Points : 1 177
    Points
    1 177
    Par défaut
    Java est-il un choix coûteux pour les entreprises ?

    Citation Envoyé par thelvin Voir le message
    C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.
    Webservice vs EJB. Je n'ai rien contre des exemples mais franchement on s'éloigne du sujet. D'autant plus que les Webservices ne sont pas propres à Java.

    Je pensais qu'on parlerait d'architecture globale, des frameworks, d'agilité, des cycles de développement, des coûts, la verbosité...
    - Pourquoi les boites choisissent Java ?
    - Les courbes d'apprentissage des différents Framework ?
    - Les performances globales.
    - Coût d'un Dev Java vs Dev .NET vs C++ vs PHP
    - Pourquoi Scala cartonne
    - Les défauts de Java


    Citation Envoyé par B.AF Voir le message
    C'est quand même dingue de lire autant de condescendance.
    Quant à des débats hyper techniques, excuses moi mais on parle de sujet quand même très généraux et pas très complexes.
    Je pourrais te dire que si tu trouves ça hyper technique, il serait utile de ré-évaluer ta notion d'hyper
    "Très généraux", non ils sont spécifiques. Je n'ai pas parlé de complexité mais contrairement à toi je pense qu'on s'éloigne du sujet avec cette histoire d'EJB.S

  17. #97
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    EJB ? Annotation ? Tests ? Couches ? Multiplication des frameworks ?
    Je suis ravi pour toi si tu peux aujourd'hui créer des bus de service sans overhead.

    Citation Envoyé par batataw Voir le message
    Webservice vs EJB. Je n'ai rien contre des exemples mais franchement on s'éloigne du sujet. D'autant plus que les Webservices ne sont pas propres à Java.
    Justement, quel est le point architectural de privilégier une exposition spécifique ou universelle ? Quels sont les risques ? Est-ce que le WS est la réponse ? Est-ce que l'EJB est un élément technique ou un élement structurant dans une architecture Java distribuée? Quelles sont les raisons qui devraient mener à choisir des Web services ?

    Citation Envoyé par batataw Voir le message
    - Pourquoi les boites choisissent Java ?
    Et quelles solutions si elles n'ont pas choisi QUE java ? Ce qui reste le cas majoritaire.

    Citation Envoyé par batataw Voir le message
    - Les courbes d'apprentissage des différents Framework ?
    - Les performances globales.
    Et ça n'a rien à voir avec la multiplication des frameworks dans l'architecture et l'approche technologique ?
    Apprendre la persistence, c'est différent pour un guru SQL et un noob en développement, l'approche MVC est différente entre un architecte qui se penche sur le pattern et le développeur qui en utilise une implémentatio dans un framework. Pire que ça, il y a les design fondamentaux : API, Services, composants, programmation par convention, para / multithread...
    Il y a aussi les contaminations entre les frameworks :
    - Dépendances logicielles
    - Multiplication des équivalences (n versions du même framework, ou de fraemwork équivalent mais liés à d'autres framework)
    - Fermeture technologique (faut-il un framework qui fasse tout - spring - ou un framework dont les responsabilités sont définies - guice)
    - Fermeture intellectuelle : faut-il n'utiliser qu'un ORM ou faut-il moduler l'approche en fonction des cas ?
    ....

    Concernant les performances, sur quelle base ??? C'est le doux rêve du benchmark universel.
    La seule performance valable est celle d'usage. Je ne connais pas un seul vrai architecte qui sacrifiera la perf de l'appli au profit de modes architecturales douteuses. (Comme la prolifération des interfaces ou des aspects)

    Citation Envoyé par batataw Voir le message
    - Coût d'un Dev Java vs Dev .NET vs C++ vs PHP
    Question stupide. Coût du choix de l'architecture. Le coût du développement en Java lui même est économiquement non intéressant.
    La vraie question de ce sujet est de dire : quel est le coût réel d'une architecture ouverte basée sur des frameworks hétérogénes et une architecture fermée basée sur un développement local. Quelle que soit la technologie. On ne fera pas du Web en C++, ni du calcul intensif en PHP, on ne fera pas de la progfonctionnelle en Java, on ne fera pas un client lourd en php....Sauf à considérer qu'il n'existe qu'une seule architecture viable qui existe pour ces 3 technos, voir pour toutes les technos, c'est juste une question polémique.

    Quels avantages dans cette configuration offre la plateforme java ?
    - Uniformité entre applications Java --> EJB
    - Interopérabilité --> Web Services

    Citation Envoyé par batataw Voir le message
    - Pourquoi Scala cartonne
    C'est vrai que choisir Scala sur la JVM n'est pas technique et que de savoir qu'il y a une mode autour de ce langage est un point de très haut niveau dans une conception logicielle....

    Citation Envoyé par batataw Voir le message
    - Les défauts de Java
    Non, le sujet, c'est au dessus de Java, c'est le coût réel des architectures objet basées sur des technologies libres / ouvertes.
    Là où le sujet tombe à l'eau, c'est qu'aucun framework ne peut :
    - Créer de la logique métier
    - Anticiper un comportement métier
    - Créer de la valeur fonctionnelle immédiate
    Java n'a pas de défauts. Comme toutes les techno, il a son sweet spot et sa zone d'inutilité ou d'improductivité et ses manques. Java est et reste une technologie majeure, riche et fiable. Sauf que sa richesse devient son talon d'Achille dans le temps car c'est une richesse éparpillé car communautaire.

    Avant de prendre de la hauteur, il faut savoir prendre du recul

  18. #98
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Je crois qu'à trop chercher tes formules, tu en as oublié la conception globale de a à z de ton post

    En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.

    Et quand tu parles de problèmes de conception globale, c'est justement qu'il faudrait arrêter de faire de la conception avec des choix uniquement techniques réputés ouverts pour éviter de choisir et faire "comme tout le monde".

    De la même façon je trouve insupportable ceux qui ne résonnent qu'en relationnel ou en SQL.

    Il y a deux chose dangereuses en architecture logicielle :
    - Les dogmes, comme le couplage faible, les couches, les services
    - Les modes, comme les web services
    je suis tout à fait d'accord avec toi

  19. #99
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par thelvin Voir le message
    C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.

    Ceci pour une raison très simple, c'est la même que pour obtenir la paix, la sécurité et le bonheur de tous les êtres.
    Résoudre à la fois tous les problèmes des technologies de développement, c'est probablement impossible, et au mieux c'est tellement difficile qu'on n'arrive pas vraiment à l'aborder. Ça nécessite encore beaucoup de temps d'évolution. À moins que la longévité soit significativement augmentée au cours de notre vie, nous ne verrons jamais une chose pareille.
    Ça ne signifie pas qu'on doit renoncer à essayer, seulement c'est extrêmement compliqué et ce n'est pas avec des raccourcis qu'on va décrire ses idées. D'ailleurs il y a deux questions qui sont distinctes mais interdépendantes :
    - Quel genre de technologie résoudrait les problèmes actuellement observés et prédits ?
    - Comment les faire adopter par le monde ?

    Et pour l'amour du ciel qu'on vienne pas me dire "mais moi je prétends pas que j'ai la solution, je dis juste que ça et ça c'est un problème." Les problèmes ont toujours des origines, c'est un prêté pour un rendu, tout le temps. On peut tant qu'on veut trouver qu'il aurait mieux valu pas avoir le prêté vu le rendu qu'on se paie, mais ça ça dépend des besoins. Des besoins il y en a autant que d'idées de réalisations, ils sont adressés de différentes manières, plus ou moins dans le détail, qui colleront plus ou moins avec l'idéal. Mais nier la multitude des besoins c'est chercher à stagner et le monde ne le fera pas pour vous. Personnellement je pense qu'il a bien raison.

    Ça vous va, ça, comme hauteur prise ?
    Ben disons que bof bof
    Je ne nie pas la multitude des besoins mais je constate simplement que l'on a très peu, voir pas du tout de solutions tout intégrées comme on a pû avoir à l'époque des L4G. Et sans vouloir refaire des L4G, je trouve qu'il y a encore une marge entre les frameworks unitaires que l'on peut trouver et un semblant de liant entre tout ça.

  20. #100
    Membre éclairé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    549
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 549
    Points : 704
    Points
    704
    Par défaut
    Ce mec ne sort pas grand chose de nouveau....

    Java a permis de faire de grosses économies de temps en terme de développement, après si aucun suivi n'est fait au niveau de la qualité, c'est à se demander ce que fait le DSI, chargé de projet et architecte...

    Qu'une entreprise décide de faire son propre framework, ça prendra beaucoup de temps quel que soit le langage.

    La très grande diversité de Java démontre qu'il n'y a pas une seul réponse à un problème.
    Lorsqu'un choix est fait au niveau d'un IDE, librairie ou framework, il faut un minimum se renseigner, voir ses possibilités et non les prendre car ils sont à la mode.... Faut voir si on a intérêt à les employer...

    Je crois que cette étape est très souvent négligée.... après il y a blâme... faut que les DSI commencent à assumer leurs responsabilités.

Discussions similaires

  1. Java est-il un choix coûteux pour les entreprises ?
    Par Idelways dans le forum Actualités
    Réponses: 0
    Dernier message: 14/03/2011, 17h44
  2. Quel est l'index qui sert pour les For Each ?
    Par Nixar dans le forum VB.NET
    Réponses: 5
    Dernier message: 04/06/2007, 09h23
  3. qu'est ce il faux aprendre pour les jsf?
    Par developper2006 dans le forum JSF
    Réponses: 1
    Dernier message: 05/03/2007, 23h55
  4. [EasyPHP] Est ce que EasyPHP est gratuit pour les entreprises ?
    Par lenouvo dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 16
    Dernier message: 27/10/2005, 16h14
  5. Quel est l'équivalent de Findcomponent pour les Forms ?
    Par Ben_Le_Cool dans le forum Composants VCL
    Réponses: 12
    Dernier message: 23/09/2005, 13h48

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