+ Répondre à la discussion Actualité déjà publiée
Page 5 sur 11 PremièrePremière 123456789 ... DernièreDernière
  1. #81
    Membre habitué
    Profil pro
    Inscrit en
    juin 2005
    Messages
    138
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juin 2005
    Messages : 138
    Points : 173
    Points
    173

    Par défaut

    Il sert un peux à rien ce thread car tout le monde sait que tout est une question de cout & moyen || contrainte.

    J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate. On a gagné du temps sur nos DAO et on a pu à coté réfléchir sur le clustering, le load-balancing...

    Actuellement sur un projet sans moyen, beh je met en place une archi orienté ejb3/JPA. On me donnerait plus de moyen et les contraintes seraient plus fortes, bah je ferais pas forcément différemment.

    Je peux vous dire que l'ORM couplé à l'OXM, et bien je gagne pas mal de temps et de plus, c'est totalement flexible. Mon appli sera customizable depuis mes xsd (dans la limite du raisonnable).

  2. #82
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par lespoches Voir le message
    Il sert un peux à rien ce thread car tout le monde sait que tout est une question de cout & moyen || contrainte.

    J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate. On a gagné du temps sur nos DAO et on a pu à coté réfléchir sur le clustering, le load-balancing...

    Actuellement sur un projet sans moyen, beh je met en place une archi orienté ejb3/JPA. On me donnerait plus de moyen et les contraintes seraient plus fortes, bah je ferais pas forcément différemment.

    Je peux vous dire que l'ORM couplé à l'OXM, et bien je gagne pas mal de temps et de plus, c'est totalement flexible. Mon appli sera customizable depuis mes xsd (dans la limite du raisonnable).
    H24 7/7 ça n'a jamais signifié 100 ms de latence max, ni des algorithmes complexes en grid ,etc,etc....
    Dans le genre hors sujet péremptoire :

  3. #83
    Membre habitué
    Profil pro
    Inscrit en
    juin 2005
    Messages
    138
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juin 2005
    Messages : 138
    Points : 173
    Points
    173

    Par défaut

    Je me suis mal exprimé mais dans le fond je me comprends.
    Quand tu recoie un message d'alerte et que le but de ton soft c'est d'alerter les secours afin de sauver des personnes en détresse !!! Et pourtant oui, ya de l'H...

    http://fr.wikipedia.org/wiki/Cospas-Sarsat

  4. #84
    Membre habitué
    Profil pro
    Inscrit en
    juin 2005
    Messages
    138
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juin 2005
    Messages : 138
    Points : 173
    Points
    173

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Dans le genre hors sujet péremptoire :
    ... Wow mais tu es d'une humeur ! Faut changer de métier mon gars !

  5. #85
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 519
    Détails du profil
    Informations personnelles :
    Âge : 59
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 519
    Points : 16 942
    Points
    16 942
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par lespoches Voir le message
    J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate.
    H24 7/7 chez moi ça fait 0 minutes de coupure....

    Et j'ai travaillé sur des softs comme ça..

    Mais sans Hibernate re


    Nan, sérieux, ça fait pas sérieux...

    Ou alors c'est que c'est pas H24 7/7...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  6. #86
    Membre habitué
    Profil pro
    Inscrit en
    juin 2005
    Messages
    138
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juin 2005
    Messages : 138
    Points : 173
    Points
    173

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    H24 7/7 chez moi ça fait 0 minutes de coupure....
    C'est tout à fait vrai et c'est bien pour ca que des personnes sont payé pour faire des etudes de risques (inondation, chimique, viral...)

    Mais malgrès toute ces études et tout ce que tu peux mettre en oeuvre pour parer à la moindre éventualité, eh bien il arrive que ca merde d'où le pouillem accordé car c'est pas de l'embarqué.


    Tout ca pour dire que les ORM sont très largement répandu et qu'ils conviennent à la majorité des projets (même ceux à risque). D'autre part, je ne pense pas que l'API de persistance Java est vu le jour comme ca juste pour le fun. Il s'agit d'une capitalisation de best-practice sur un nombre majoritaire de projet orienté nouvelle techno.

  7. #87
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par lespoches Voir le message
    Tout ca pour dire que les ORM sont très largement répandu et qu'ils conviennent à la majorité des projets (même ceux à risque). D'autre part, je ne pense pas que l'API de persistance Java est vu le jour comme ca juste pour le fun. Il s'agit d'une capitalisation de best-practice sur un nombre majoritaire de projet orienté nouvelle techno.
    Oui enfin nouvelle techno, hibernate, ca reste du java et une librairie, rien de plus. C'est plus un concept qu'une techno.

    Après une autre réalité, c'est que ce n'est pas parce que la majorité utilise une techno que cela en fait la meilleure. C'est la plus répandue. Point.

    Les ORM ne conviennent pas à la majorité des projets : embarqué ? client mobile ? pas de db ? traitements de fichier ? Calculs scientifiques ?

    L'ORM c'est surtout un choix. Souvent mal fait parce que facilité, et après mal utilisé parce qu'on se dit "bon ben je vais générer du code maintenant". C'est surtout ça la réalité de l'ORM.

    Et en plus, ils ne fonctionnent pas tous de la même façon, n'ont pas tous les mêmes patterns et les même contraintes.

    C'est comme SQL Server et ORACLE : connaitre le SQL n'a jamais garanti qu'on puisse se servir parfaitement des deux.

    C'est comme hibernate : connaitre le java n'a jamais garanti qu'on s'en serve correctement. Je serai curieux, parce que je n'en ai jamais rencontré en fait, de connaitre la statistique exacte du nombre de personnes qui ont déjà forké, modifié ou simplement regardé à l'intérieur du moteur pour comprendre.

    Je dirai 5%. Pas plus. Comme les utilisateurs de JBoss d'ailleurs.

  8. #88
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 844
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 844
    Points : 7 157
    Points
    7 157

    Par défaut

    Si tu regardes du coté cayenne, je suis à l'origine de quelques modifications du code de la version 3.0. Mais c'est un mapper pour moi, pas un ORM et je m'en sers surtout pour éviter de faire directement du SQL dans mon code client.

    J'ai adopté ce mapper pour quelques projets légers parce qu'il est pas trop invasif et parce que sa communauté était très sympa et que les gens de la mailing list répondaient gentiment à mes questions sans essayer de me faire passer pour un idiot.

  9. #89
    Candidat au Club
    Homme Profil pro
    Ingénieur Concepteur Senior
    Inscrit en
    janvier 2005
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Concepteur Senior

    Informations forums :
    Inscription : janvier 2005
    Messages : 6
    Points : 3
    Points
    3

    Par défaut

    Citation Envoyé par _skip Voir le message
    Si tu regardes du coté cayenne, [...]

    J'ai adopté ce mapper pour quelques projets légers parce qu'il est pas trop invasif et parce que sa communauté était très sympa et que les gens de la mailing list répondaient gentiment à mes questions sans essayer de me faire passer pour un idiot.
    Ce qui voudrait dire que ce n'est pas le cas du côté d'Hibernate...

  10. #90
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Bof, en même temps 90% des questions sur le groupe nh mériterait un RTFM sans sommation.
    Je crois que le plus drôle c'est que "comment gérer une session" doit être demandé 52 fois par jour en moyenne.

  11. #91
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 657
    Points : 8 726
    Points
    8 726
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Ah oui, c'est un peu d'humour dans ce monde de brute, mais c'est la fatigue tous les jours de supporter ceux qui veulent faire de la techno pour faire de la techno, du process pour faire du process, du sgbd pour faire du sgbd...

    Ca bouffe une énergie...
    Pas mal, mais réversible...

    Ça bouffe une énergie folle de supporter ceux qui veulent en rester à l'assembleur, utiliser les api les plus bas niveau pour accéder aux données de la base, etc...

    La vérité est sûrement entre les 2
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #92
    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 : 48
    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 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Toutes ces histoire de framework et d'ORM sont les plus belles merdes mercatiques que l'on a fait depuis l'existence de l'informatique. Si vous voulez avoir l'assurance de ne pas finir à temps votre prijet et que ce dernier soit inexploitable lors de la montée en charge, alors allez-y, amusez vous bien avec Hibernate et les frameworks associé comme JPA...

    Voici un extrait de l'article que je suis en train d'écrire sur les dérives de ce genre d'immondices...

    6 – Pourquoi pas un ORM ?

    Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
    Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
    Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

    Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…


    A lire sur le sujet :
    http://www.dulcian.com/Articles/Thic...ited_final.htm
    http://thehelsinkideclaration.blogsp...vc-part-2.html

    A +
    Moi ça me fait penser aux débats Assembleur->C puis C->C++ puis C++->Java.
    Regardez aussi Windows XP ou Vista par rapport à Windows 3.1 (oui je parle aux vieux là ). Quand j'ai commencé l'informatique on faisait tout avec le code sur une disquette et seule la partie devant s'exécuter était chargée dans mon monstre de 512Ko !!
    Qu'est-ce que cela peut bien faire d'écrire une requête en base avec SQL ou avec HQL ? Vous croyez que parce que vous avez écrit vous même la requête "à la main" elle est meilleure ? C'est TOTALEMENT faux. Il s'agit simplement d'une facilité d'écriture, seulement.
    La très grande majorité des requêtes SQL sont de simples requêtes avec 1 ou 2 jointures et c'est tout à fait normal avec l'approche objet. Car dans le monde objet, on charge un objet et on navigue de proche en proche dans les relations entre objets. Donc de simples requêtes du genre "donne moi les dossiers suivis par ce collaborateur". Alors à quoi cela sert d'écrire "à la main" ?
    Par contre, si on a des requêtes plus complexes dans des cas limites parce que l'on a une vraie requête "transverse" aux objets de toute manière, l'ORM ne va pas nous aider car il est là pour faire du chargement "simple" en général. Dans ces cas, où même une requête HQL pourra être faite, on peut tout à fait déclarer la requête directement en SQL "natif".

    Donc où est le problème, vraiment je ne vois ABSOLUMENT pas ?!

  13. #93
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 657
    Points : 8 726
    Points
    8 726
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par ego Voir le message
    Moi ça me fait penser aux débats Assembleur->C puis C->C++ puis C++->Java.
    Regardez aussi Windows XP ou Vista par rapport à Windows 3.1 (oui je parle aux vieux là ). Quand j'ai commencé l'informatique on faisait tout avec le code sur une disquette et seule la partie devant s'exécuter était chargée dans mon monstre de 512Ko !!
    Qu'est-ce que cela peut bien faire d'écrire une requête en base avec SQL ou avec HQL ? Vous croyez que parce que vous avez écrit vous même la requête "à la main" elle est meilleure ? C'est TOTALEMENT faux. Il s'agit simplement d'une facilité d'écriture, seulement.
    La très grande majorité des requêtes SQL sont de simples requêtes avec 1 ou 2 jointures et c'est tout à fait normal avec l'approche objet. Car dans le monde objet, on charge un objet et on navigue de proche en proche dans les relations entre objets. Donc de simples requêtes du genre "donne moi les dossiers suivis par ce collaborateur". Alors à quoi cela sert d'écrire "à la main" ?
    Par contre, si on a des requêtes plus complexes dans des cas limites parce que l'on a une vraie requête "transverse" aux objets de toute manière, l'ORM ne va pas nous aider car il est là pour faire du chargement "simple" en général. Dans ces cas, où même une requête HQL pourra être faite, on peut tout à fait déclarer la requête directement en SQL "natif".

    Donc où est le problème, vraiment je ne vois ABSOLUMENT pas ?!
    Allo, ici un vieux...
    Alors, oui, avec Windows 3.1 on faisait tourner de gros programmes de 512ko (énorme !) et maintenant il ferait 5Mo...
    Quelque part, on s'en fout un peu... non ? Il est généralement admis que windows bouffe beaucoup (trop) de ressources, Linux pour la même chose serait largement plus light en mémoire...
    Enfin, je comprends ton point de vue... Les anciens ne veulent plus trop s'adapter et se tourne vers le passé en disant "ah, c'était mieux avant"...
    Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
    Il faut vivre avec son temps...
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  14. #94
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 282
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 282
    Points : 2 558
    Points
    2 558

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    ... Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
    Il faut vivre avec son temps...
    Puisqu'on parle de ce bon vieux Mainframe et que c'est mon domaine professionnel, je vais ajouter une modeste contibution au présent débat en citant un "gourou" en matière de SGBD sur le Mainframe (DB2 z/OS), à savoir Susan Lawson, qui sait de quoi elle parle :

    Canonical Database Architecture and DB2 Performance ... Really ?

    Sans recouper totalement l'article de SQLpro, on peut noter quand même quelques points de convergence.

    Quelques morceaux choisis :

    As with any database design, the best performance is achieved using direct access via SQL to the database objects. Getting only the data that’s needed when it’s needed is the key to achieving high performance. Introducing layered access to your data stores can negatively impact database performance. A generic data access object lends itself to generic database performance. The performance issues created by generic data access can’t be resolved by tuning the database or system resources, such as adding memory or CPU. This is solely a problem of the application.
    ...
    The key to high-performance database design is to move data-intensive processes as close to the data as possible. This allows for filtering of data to occur close to the data, and less data to be passed around and processed by other data processing layers.
    ...
    You should seriously consider the costs associated with generic design and denormalization. Consistent use of denormalization as a solution to data access costs for a generic design can slow or even halt a company’s update operations. One company that experienced this problem eventually had to abandon their entire development effort and restart with a more specifically tuned design. This occurred after investing years of development time and money. Even if they could have achieved acceptable performance, their other goal of having a flexible, accessible database (via SQL and Web applications) could never have been realized.

    ... etc ... etc ...
    Il va sans dire que je partage totalement ce point de vue ...

  15. #95
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 657
    Points : 8 726
    Points
    8 726
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Puisqu'on parle de ce bon vieux Mainframe et que c'est mon domaine professionnel, je vais ajouter une modeste contibution au présent débat en citant un "gourou" en matière de SGBD sur le Mainframe (DB2 z/OS), à savoir Susan Lawson, qui sait de quoi elle parle :

    Canonical Database Architecture and DB2 Performance ... Really ?

    Sans recouper totalement l'article de SQLpro, on peut noter quand même quelques points de convergence.

    Quelques morceaux choisis :



    Il va sans dire que je partage totalement ce point de vue ...
    Il se pourrait que ton point de vue soit quelque peu faussé.
    Si tu travailles sur mainframe, ce n'est certainement pas sur des applications pour 100 utilisateurs. Du coup, le côté performance a un poids peut-être un peu supérieur.
    Il est certains aussi qu'avec une application plus proche du temps réel, on ne va pas s'amuser à traverser n couches...
    Ne crois-tu pas en fin de compte qu'il est plus juste (et sage) de dire que finalement, tout dépend de ce qu'on développe.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  16. #96
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 282
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 282
    Points : 2 558
    Points
    2 558

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Il se pourrait que ton point de vue soit quelque peu faussé.
    Si tu travailles sur mainframe, ce n'est certainement pas sur des applications pour 100 utilisateurs. Du coup, le côté performance a un poids peut-être un peu supérieur.
    Il est certains aussi qu'avec une application plus proche du temps réel, on ne va pas s'amuser à traverser n couches...
    Certes ... ce n'est pas faux ...

    Ne crois-tu pas en fin de compte qu'il est plus juste (et sage) de dire que finalement, tout dépend de ce qu'on développe.
    Voilà une réflexion qui me semble frappée au sceau du bon sens et que je ne peux qu'approuver ... C'est d'ailleurs en partie ce qu'écrit Susan Lawson dans la conclusion de l'article que j'ai cité.

  17. #97
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 657
    Points : 8 726
    Points
    8 726
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Voilà une réflexion qui me semble frappée au sceau du bon sens et que je ne peux qu'approuver ... C'est d'ailleurs en partie ce qu'écrit Susan Lawson dans la conclusion de l'article que j'ai cité.
    Damned, on va m'accuser de plagiat (désolé, je n'avais pas lu)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  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 : 48
    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 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Allo, ici un vieux...
    Alors, oui, avec Windows 3.1 on faisait tourner de gros programmes de 512ko (énorme !) et maintenant il ferait 5Mo...
    Quelque part, on s'en fout un peu... non ? Il est généralement admis que windows bouffe beaucoup (trop) de ressources, Linux pour la même chose serait largement plus light en mémoire...
    Enfin, je comprends ton point de vue... Les anciens ne veulent plus trop s'adapter et se tourne vers le passé en disant "ah, c'était mieux avant"...
    Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
    Il faut vivre avec son temps...
    Au risque de ne pas t'avoir compris, je crois que c'est toi qui n'a pas compris ma remarque. Je ne suis justement pas attaché au passé et je pense que ceux qui sont contre les ORM sont parfois des gens attachés au passé, justement.

    Donc vive l'avenir !!

  19. #99
    Invité
    Invité(e)

    Par défaut

    Au risque de ne pas t'avoir compris, je crois que c'est toi qui n'a pas compris ma remarque. Je ne suis justement pas attaché au passé et je pense que ceux qui sont contre les ORM sont parfois des gens attachés au passé, justement.

    Ce n'est pas parce que c'est une évolution qu'elle est bonne.
    Ces arguments me font penser au gens qui soutiennent les technique du "Make an web 2.0 app only with drag'n drop" ...

    Les ORM ont le gros défaut d'être une couche technologique a connaitre en plus pour le développeur : un développeur qui utilise un ORM sans connaitre SQL va droit dans le mur. Donc au final le dev doit connaitre le langage + SQL + l'ORM. Une bonne évolution n'est pas censé enlever des connaissances nécessaires ?

    Mais vous inquiétez pas les MVP et autre expert vont bientôt trouver une techno pour "faciliter" la passerelle entre l'orm et le langage ... mince ça existe deja (activerecord par exemple)... on appelle ça comment ? Un Object to Object - Relationnal Mapping ? A quand un OOOOROOOOM ?

    Je ne dit pas par la que ce sont des mauvais produits : leurs utilisation dans l'industrie est très répandu donc je n'aurais pas la prétention de dire que tout le monde se plante.

    Mon post a l'air d'un troll, mais je pense qu'il faut se souvenir de ma première phrase.

  20. #100
    Membre expert
    Profil pro
    Inscrit en
    août 2006
    Messages
    3 192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 3 192
    Points : 3 986
    Points
    3 986

    Par défaut

    Les ORM ont le gros défaut d'être une couche technologique a connaitre en plus pour le développeur : un développeur qui utilise un ORM sans connaitre SQL va droit dans le mur. Donc au final le dev doit connaitre le langage + SQL + l'ORM. Une bonne évolution n'est pas censé enlever des connaissances nécessaires ?
    Déjà, SQL doit faire partie (je l'espère) du savoir de base d'un développeur.
    Donc c'est un faux problème.
    Pour ce qui est de la couche à connaitre en plus, c'est alors valable pour tous les autres frameworks autre que ORM. On est quand même censé ne pas réinventer la roue à chaque fois, et donc si on utilise d'autres briques logicielles, la moindre des choses c'est d'apprendre à bien s'en servir, ou alors il faut changer de boulot.
    Encore un faux problème à mon sens.

Discussions similaires

  1. Les IDE sont-ils dangereux pour les développeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 85
    Dernier message: 13/05/2014, 12h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 20h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 09h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 09h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 24/11/2008, 00h13

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