Discussion :

[pcaboche]

Je préconise l'écriture des requêtes en SQL dans les classes modèles

Je préconise plutôt l'écriture de procédures stockées pour des traitements un peu complexes et nécessitant plusieurs requêtes.

L'avantage des procédures stockées, c'est que:
- on peut définir une suite de requêtes et faire des traitements assez complexes
- on peut gérer ses transactions dans la procédure

Et pour reprendre tes arguments:
- les requêtes sont centralisées (mais en plus on peut les modifier sans avoir à tout recompiler et re-déployer)
- on identifie très facilement les paramètres
- on gagne en transparence et en performances (tout est exécuté directement sur le serveur, pas besoin d'échanger de données intermédiaires entre l'appli et le SGBD)

L'inconvénient, c'est que si on a beaucoup de fonctionnalités nécessitant seulement une requête SQL, on se retrouve avec beaucoup de procédures à gérer...

Mais bon, si toutes les fonctionnalités peut être implémentées en une seule requête à chaque fois, c'est qu'on ne travaille pas sur un système vraiment complexe, et dans ce cas ça n'a pas grande importance si on utilise des requêtes séparées, un ORM ou autre chose...

@pcaboche
joli post, ça sent sacrément le vécu tout ça, dis donc...

1 stage et 1 entreprise (mon entreprise actuelle. L'entreprise précédente avait d'autres défauts au moins aussi irritants mais de nature différente).

Je ne vais pas me la jouer Mireille Dumas, mais tu devrais consulter pour te faire du bien.

J'ai consulté de par le passé.

Il en résulte que:
- ça ne sert à rien de garder ses problèmes pour soi. Mettre ses problèmes sur le papier est libératoire et constitue un début de thérapie
- le fait de partager ses pensées et expérience permet de voir que l'on n'est pas seul à rencontrer ce problème
- voir des gens partager votre opinion est rassurant, voire glorifiant
- si d'autres personnes trouvent la discussion utile, tout le monde en ressort gagnant

Et puis j'aime pas Mireille Dumas à cause des conneries qu'elle a pu raconter sur les jeux de rôles au milieu des années 90.

Mireille, si tu nous lis (on ne sais jamais, peut-être que tu prépares à nouveau à cracher ton venin, stigmatiser et proférer des propos diffamatoires envers un groupe d'individus choisi au hasard), sache qu'une majorité d'anciens rôlistes sont des personnes parfaitement saines d'esprit et certains occupent aujourd'hui des postes à responsabilités. Les quelques cas qui ont mal tourné avaient vraisemblablement des problèmes d'ordre psychologiques, éventuellement entretenus par le ramassis de conneries dont la télévision nous abreuve quotidiennement.

Mais là je crois qu'on s'éloigne légèrement du sujet original, non ?

[erwanlb]

Justement, si tu n'as jamais eu l'occasion....blablablabla....
P.

Un projet sérieux n'est pas forcément un projet de type boursier (bien au contraire, donner les moyens à des petits rigolos de créer des crises boursières, est ce bien sérieux ? )

Tout projet donnant du boulot et à bouffer peut être considéré comme sérieux....

Pour le reste, tu pars dans un blabla qui s'éloigne un peu trop du sujet dans le sens ou à part montrer à quel point tu prends les gens de haut, te considère comme meilleur parce que n'utilisant pas (ou ne voulant pas) d'ORM...rien que pour ça, j'estime que tu es loin d'être sérieux et professionnel....

A défaut d'avoir un rasoir tu l'auras été

[erwanlb]

@pcaboche
joli post, ça sent sacrément le vécu tout ça, dis donc...

Je ne vais pas me la jouer Mireille Dumas, mais tu devrais consulter pour te faire du bien. Tu ferais moins de cauchemars idée de groupe : les informaticiens anonymes

Ouf je suis pas le seul à avoir l'impression qu'il a une très très grosse frustration vis à vis d'un vécu mais pas du tout vis à vis du sujet des ORM...

[imikado]

Je précise quand je parle de SQL coté couche modèle qu'on utilise les prepare statement de pdo qui me semble être un juste milieu


Note: c'était SQL vs language d 'ORM

[erwanlb]

1 stage et 1 entreprise (mon entreprise actuelle. L'entreprise précédente avait d'autres défauts au moins aussi irritants mais de nature différente).

J'ai consulté de par le passé.

Il en résulte que:
- ça ne sert à rien de garder ses problèmes pour soi. Mettre ses problèmes sur le papier est libératoire et constitue un début de thérapie
- le fait de partager ses pensées et expérience permet de voir que l'on n'est pas seul à rencontrer ce problème
- voir des gens partager votre opinion est rassurant, voire glorifiant
- si d'autres personnes trouvent la discussion utile, tout le monde en ressort gagnant

Et puis j'aime pas Mireille Dumas à cause des conneries qu'elle a pu raconter sur les jeux de rôles au milieu des années 90.

Mireille, si tu nous lis (on ne sais jamais, peut-être que tu prépares à nouveau à cracher ton venin, stigmatiser et proférer des propos diffamatoires envers un groupe d'individus choisi au hasard), sache qu'une majorité d'anciens rôlistes sont des personnes parfaitement saines d'esprit et certains occupent aujourd'hui des postes à responsabilités. Les quelques cas qui ont mal tourné avaient vraisemblablement des problèmes d'ordre psychologiques, éventuellement entretenus par le ramassis de conneries dont la télévision nous abreuve quotidiennement.

Mais là je crois qu'on s'éloigne légèrement du sujet original, non ?

2 boites wahou....quel vécu

C'est assez marrant de voir que c'est toi qui t'es éloigné du sujet tout en allongeant sur le divan et tout en faisant ta Mireille Dumas en crachant ton venin pour stigmatiser un groupe d'individus qui utilisent un outil que tu n'apprécies pas...

Mireille n'a jamais eut un ton condescendant par contre...

A la semaine prochaine pour notre prochaine consultation...

[_skip]

Les ORMs et les procédures stockées ne sont pas mutuellement exclusifs.

Il y a des projets très complexes où l'on peut accepter l'overhead de framework (typiquement un ORM) en tenant compte de l'éternel trade-off entre vitesse de dév, facilité de maintenance et performance.

Je préconise l'écriture des requêtes en SQL dans les classes modèles

Cela permet:
1. De séparer et centraliser les requêtes (un des avantages du MVC)
2. Gagner en performances et en transparence (permet facilement de switcher vers des vues si nécessaire)
3. Identifier les paramètres des requêtes (plus facile à sécuriser)

Tu parles d'un modèle au sens classe utilitaire qui n'est pas un controlleur, ou d'un modèle au sens entité métier? Style active record?

[imikado]

@skip je parle dans un framework d'une classe modèle, en général au moins un couple de classe par table (mapper/factory plus row)

[chaplin]

Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".

Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:

1er temps:
- l'entreprise exprime un besoin, elle fait un appel d'offres
- un consultant arrive et propose sa solution
- le consultant fait du RAD et respecte les délais
- le client est content, le consultant touche son gros chèque
- on met la solution en prod

2ème temps:
- au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
- on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)- au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n

J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...

P.

, je fairais juste une nuance, c'est qu'avec un RAD, on peut faire du RAD, mais on peut aussi faire du génie logiciel avec son cerveau pour rattraper les conneries d'une mauvaise architecture, mais le client ne veut pas le reconnaître, d'où l'étape 1 voulu par le client.

[pcaboche]

(bien au contraire, donner les moyens à des petits rigolos de créer des crises boursières, est ce bien sérieux ? )

Ça c'est un autre débat (est-ce que les métiers vraiment utiles à la société sont récompensés à leur juste valeur ?) dans lequel je n'ai pas vraiment envie de rentrer.

L'idée importante, c'est que c'est le genre de système qui doit être performant et tenir la charge, mais merci de déformer mes propos...

2 boites wahou....quel vécu

Et bien oui... je ne suis pas du genre à rentrer dans une boite pour quelques mois, y laisser ma petite "trace" personnelle (généralement sous la forme d'un étron nauséabond), toucher mon gros chèque, et me barrer avant que tout n'explose à la figure...

Quand je rentre dans une boite, c'est généralement dans le but de travailler sur des projets qui s'inscrivent sur la durée, d'apporter des solutions et de faire un suivi des évolutions.

Généralement ça marche plutôt bien, jusqu'au jour où la boite demande que l'on fasse des "compromis". À partir du moment où l'ensemble de ces compromis représentent plus de contraintes que de chercher un nouveau "challenge", cela marque souvent le début de la fin pour la collaboration professionnelle.

La durée du contrat dépend donc souvent du délai au bout duquel la phase de "compromis" apparait, et n'a donc aucun rapport avec l'appréciation de l'employeur (même si curieusement, cette appréciation diminue rapidement peu après le refus dudit "compromis").


Tout ça pour dire (ne t'en déplaise, j'aime bien les explications détaillées et argumentées) que c'est pas facile de cumuler les boites quand on reste 4 ans dans la même entreprise. Je n'ai pas encore le don d'ubiquité...

Au final, il s'agit vraisemblablement de savoir dans quel camp on se trouve:
- les gens qui essayent de faire leur boulot correctement dans le but de trouver de réelles solutions
- les gens qui veulent exploiter le système: donner l'illusion d'être de grands professionnels mais, faute d'arguments convaincants, en viennent à dénigrer les autres et à déformer leurs propos
- les "petits rigolos" à qui la société a donné les moyens de "créer des crises boursières" (ou toute autre forme de pouvoir)

Et d'une certaine façon, même si on parait s'éloigner du sujet, c'est au contraire pour mieux rentrer dedans: s'interroger sur le développement informatique au sens large et se demander "quels outils (ORM, RAD ou autres) utilisent les gens du premier et du deuxième camp ?"

Pour le reste, tu pars dans un blabla qui s'éloigne un peu trop du sujet dans le sens ou à part montrer à quel point tu prends les gens de haut...

Pardon ?

Que je sache, ce n'est pas moi qui ait balancé des énormités du genre "Vu les arguments utilisés on en est au stade d'un débat genre Win/Linux, iOS/Android...." ou bien encore "Est ce que ceux qui sont contre les ORM les connaisse et les ont utilisé ?".

Mais je comprends parfaitement, c'est un comportement que j'ai rencontré de nombreuses fois sur les forums:
- on va sur un forum public
- on part du principe qu'on est un dieu dans son domaine (ex: les ORM)
- on les propos d'un type qui montre les avantages d'une approche differente
- on sous-entend que c'est un abruti et qu'il n'y connait rien sans pour autant être en mesure d'apporter de contre-argument (à part un vague "si les ORM existent c'est qu'ils sont utiles")

Et je ne suis pas le seul à qui tu t'en prennes : quand imikado a tenté de fournir des arguments, benchmark à l'appui, tu as tout simplement dénigré ses commentaires.

Donc non, je ne pense pas avoir la science infuse, mais quand un individu lance des attaques personnelles dans le seul but de se mousser, il a intérêt à être en mesure de présenter des contre-arguments pertinents plutôt que de se contenter de basses attaques personnelles.

Maintenant, juste pour information, mes remarques à ton égard sont encore relativement "gentilles" et je conseille très fortement d'arrêter tout de suite tes commentaires stériles et sans fondement ainsi que toute forme d'attaque personnelle envers tout personne fréquentant ce forum.

Jusqu'ici on en est encore au stade de la discussion, mais la prochaine étape pour toi c'est la case "modération" (et comme tu peux le constater, tout le détail se trouve déjà dans ce poste, donc ça risque de ne pas prendre très longtemps). À toi de voir...

A défaut d'avoir un rasoir tu l'auras été

Tiens, une attaque personnelle...

C'est censé être un calembour ? Un jeu de mots particulièrement recherché ? Cela ressemble plus à une reflexion de classe de maternelle...

Maintenant si ma prose t'ennuie (bien d'autres certaines personnes semblent vraisemblablement l'apprécier), personne ne t'a demandé de rester...

A la semaine prochaine pour notre prochaine consultation...

Tiens, encore une attaque personnelle puérile ?

[threshold]

Prions mes frères pour qu'un jour ( bientôt j'espère ) toutes les bases de données seront orientées objets...je rêve debout mais ça m'aide à continuer à vivre

[pcaboche]

Prions mes frères pour qu'un jour ( bientôt j'espère ) toutes les bases de données seront orientées objets...je rêve debout mais ça m'aide à continuer à vivre

Regarde du côté des bases de type NoSQL, et plus particulièrement des bases de données orientées graphes (graph database).


"Compared with relational databases, graph databases are often faster for associative data sets, and map more directly to the structure of object-oriented applications."
Source: http://en.wikipedia.org/wiki/Graph_database#Properties

[chaplin]

Au final, il s'agit vraisemblablement de savoir dans quel camp on se trouve:
- les gens qui essayent de faire leur boulot correctement dans le but de trouver de réelles solutions
- les gens qui veulent exploiter le système: donner l'illusion d'être de grands professionnels mais, faute d'arguments convaincants, en viennent à dénigrer les autres et à déformer leurs propos- les "petits rigolos" à qui la société a donné les moyens de "créer des crises boursières" (ou toute autre forme de pouvoir)

Et d'une certaine façon, même si on parait s'éloigner du sujet, c'est au contraire pour mieux rentrer dedans: s'interroger sur le développement informatique au sens large et se demander "quels outils (ORM, RAD ou autres) utilisent les gens du premier et du deuxième camp ?"

Je poserais plus générament la question, quelle framework(ORM ou non) est utilisé pour accéder à une base de données, le cas extrème étant une couche technique développée par un développeur expérimenté qui lui confert une productivité hors norme mais sort de toute convention normée.

Avec l'expérience, on est tenté de court-circuiter les frameworks, de ce fait, il est utile d'avoir un framework qui donne une certaine marge de manoeuvre pour réaliser des tâches non conventionnelles. Dans ce cas, il est bon de faire une architecture propre s'appuyant sur les briques élémentaires du framework.

Quand le framework( = cadre de travail) est imposé, on essaye de l'utiliser au mieux.

[el_slapper]

Tiens, le sens que prends le débat avec les interventions de Pcaboche me fait penser à ce vieux troll de Jeff Atwood.

Si on oublie le troll J2EE contre visual Studio(completement HS ici, et pas forcément bien argumenté dans le billet), ce qui est interessant dans ce billet, c'est la réfutation de l'argument qui veut que "l'outil difficille rend difficille de faire rapidement du code pourri" : "les gens qui savent coder proprement iront plus vite avec un outil adapté, et ferfont quand même du code propre".

En bref, le problème n'est pas un problème d'ORM, mais de compétences - et éventuellement de formation. Le problème à résoudre n'est pas simple, de toutes façons.

So ORMs help us deal with a very real problem for most enterprise applications. It's true they are often misused, and sometimes the underlying problem can be avoided. They aren't pretty tools, but then the problem they tackle isn't exactly cuddly either. I think they deserve a little more respect and a lot more understanding.

En bref, face à des problèmes complexes, on a le choix entre tout faire à la main, ce qui demande pas mal de temps et de compétences, ou passer par un ORM, ce qui demande pas mal de temps et de compétences. Si on fait l'impasse sur le temps et les compétences, on arrive aux situations décrites par Pcaboche - mais je ne crois pas que le concept même d'ORM soit en cause.

[erwanlb]

Ça c'est un autre débat ...blablablabla...

-Autre débat que tu as initié
-Aucune déformation, j'opte plutôt pour une certaine susceptibilité
-Débat HS sur ton but dans une boite...(qui démontre une seule chose, tu as de la chance...)
-Ton débat est surtout centré sur tes mauvais moments en entreprise qui n'ont rien à avoir avec les ORM puisque tes situations cités je les ai connu dans un domaine tout autre que l'informatique et donc très loin des ORM...
-Pense à balayer devant ta porte....je ne me considère pas comme un dieu des ORM puisque j'ai cité sur quel type d'ORM je bosse qui est loin de représenter tous les ORM et types de projets...prendre son interlocuteur comme miroir c'est gros comme une maison...et c'est de cette manière que tu as dit que les projets sérieux étaient les tiens dans ton domaine et que le reste ne l'était pas...et d'ailleurs perso j'attends toujours des arguments qui traitent des ORM et non pas du comportement de tes collègues ou les forums ou tu as été (3615 jedéballemavie...Mireille Dumas dépêche toi de venir...)
- Je n'ai pas dénigré les commentaires de imikado, j'ai juste dit que en lisant des benchmarks d'ORM il y en avait toujours pour remettre en question les procédures de tests (des experts en ORM)...donc pas moi...mais comme tu dis, merci de déformer mes propos...
- Pour le moussage personnel j'apprends en te lisant... se faire mousser quand ça fait plus d'une fois que je dit que je débute...t'es un sacré rigolo
-Pour ça : "Maintenant, juste pour information, mes remarques à ton égard sont encore relativement "gentilles" et je conseille très fortement d'arrêter tout de suite tes commentaires stériles et sans fondement ainsi que toute forme d'attaque personnelle envers tout personne fréquentant ce forum.", je te renvoie la balle...c'est pas beau de critiquer et de faire pareil...
-Et pour ça : "Jusqu'ici on en est encore au stade de la discussion, mais la prochaine étape pour toi c'est la case "modération" (et comme tu peux le constater, tout le détail se trouve déjà dans ce poste, donc ça risque de ne pas prendre très longtemps). À toi de voir...", on dirait tout simplement un flic qui est pressé de rentrer chez lui....
-Et la : "Maintenant si ma prose t'ennuie (bien d'autres certaines personnes semblent vraisemblablement l'apprécier), personne ne t'a demandé de rester... " , t'aime pas te faire mousser peut être ? Le mot "humble" n'a pas l'air de faire parti de ton vocabulaire...

En tout cas à part des généralités sur les ORM qu'on peut lire depuis très longtemps un peu partout, on peut pas dire que t'as apporté grand chose au sujet...me demande même si t'en avais les moyens finalement...

[Bluedeep]

Première fois que j'entends parler d'ORM

Cela dit, DAL, BLL, unit tests je connais.

Rem: .net developer

C'est vrai que NHibernate et LinqToSql n'existent que depuis 4 ans....... (et même 6 pour NHibernate 1.0).

[_skip]

Le gros avantage d'un ORM au sens hibernate ou Ebean, je pense que c'est surtout de pouvoir manipuler facilement des graphes.

Mapper une collections de POJO assez basique ayant une relation OneToOne et 2 relations oneToMany, du Style un SPECTACLE qui a N SPECTATEURS, N ORGANISATEURS et qui a UNE VILLE, ben ça vous prendra facilement 200 lignes de code en JDBC si vous voulez avoir tout cela dans de jolis graphes.
Avec un ORM bien utilisé, c'est facile de charger SPECTACLE et VILLE avec un join et le reste avec des sous-requêtes.

Si sur ce même graphe vous voulez laisser un autre traitement supprimer ou modifier des spectateurs et ensuite re-persister le tout, ça demandera pas mal de boulot avec plein de booléens pour le dirty-checking plus garder les références des ID qui ont été supprimés pour envoyer le bon DELETE qui va bien.
Après c'est un débat au cas par cas de savoir si ce genre de modif constitue une action métier que le pojo peut proposer directement ou s'il faut passer par un service dédié. Mais dans tous les cas, faire cela à la main ce sera du boulot.

Sans ORM, avec des outils comme active record, jooq, ou même du pur jdbc, la plupart du code CRUD peut être écrit voire généré facilement.
Malheureusement tout ce qui est mappage multi-table vers graphe est assez difficile à réaliser et l'absence de lazy loading peut gêner lorsqu'on veut un graphe partiel sans vouloir dupliquer toutes les classes impliquées (dans le sens où on ne peut pas accepter de balader des demi-objets, chose extrêmement casse-gueule par nature).

Tiens mais j'avais pas dit que j'utilisais pas d'ORM moi justement? Ben oui, la raison est là : je n'ai pas ou presque pas de besoin en matière de chargement de graphe, presque toutes mes tables servent à de la trace ou de la statistique, pour les autres un pojo qui mappe une table 1:1 est suffisant. En plus lorsque je charge des collections, c'est généralement du gros (10000 lignes) donc je veux surtout pas de trucs invisibles (cache).
Voilà, c'est une pure question de besoin.

[pcaboche]

Tiens, le sens que prends le débat avec les interventions de Pcaboche me fait penser à ce vieux troll de Jeff Atwood.

Juste pour re-situer les choses, j'ai juste écrit un premier poste dans lequel j'explique avoir un développeur avec de l'expérience sur les ORM (beaucoup plus d'expérience que moi dans ce domaine) et que la solution qu'on a choisie (à base de procédures stockées) nous a permis de gagner du temps en développement, de respecter les délais imposés (de manière plus ou moins arbitraire), et est globalement plus facile à maintenir.

Et c'est en substance tout ce que je dis dans ce premier poste.

Tout les postes qui ont suivi (ceux qui ont amené de nombreuses digressions par rapport au sujet original) ont été écrits en réponse aux commentaires fallacieux en provenance de erwanlb.


Maintenant pour recentrer par rapport au sujet original...

De manière générale, quand on a un problème à résoudre, on essaye d'envisager toutes les solutions possibles (même celles qui sortent des sentiers battus et/ou de son domaine de compétence) et d'évaluer leurs limites.

Après en avoir discuté avec plusieurs personnes d'horizons différents (car je ne prétends pas avoir la science infuse, contrairement à ce que certains ici essayent de le faire croire), il en ressort les choses suivantes:

- il semble qu'on atteint les limites des ORM (Hibernate, nHibernate, Entity, LINQ to Object...) plus rapidement qu'avec du SQL relativement bien maîtrisé (pas besoin de tout connaître non plus)

- le SQL a quand même certaines limites (notamment, dans plusieurs cas, afin de permettre une certaine flexibilité certains projets ont parfois recours à des requêtes SQL dynamiques... et c'est une horreur à tous les niveaux : développement, maintenance, performance. Mais bon, pas le choix, il faut faire avec parce que c'est imposé)

- d'autres solutions sont peut-être à explorer (NoSQL, bases orientées graphe...)

En bref, face à des problèmes complexes, on a le choix entre tout faire à la main, ce qui demande pas mal de temps et de compétences, ou passer par un ORM, ce qui demande pas mal de temps et de compétences.

C'est un commentaire très intéressant et qui résume bien le problème : dans les deux cas on a besoin de compétences spécifiques, mais pour quel résultat au final ?

Dans quel cas est-ce que les bénéfices (ex: gain de productivité) l'emportent sur les défauts (ex: éventuelle perte de performances) ?


----
Bon, maintenant, passons au côté moins réjouissant de cette discussion () :

- Pour le moussage personnel j'apprends en te lisant... se faire mousser quand ça fait plus d'une fois que je dit que je débute...t'es un sacré rigolo

Donc si je comprends bien, ce que tu es en train de nous dire, c'est que quand tu t'en prends violemment à certaines personnes sur un forum public, ce n'est absolument pas pour t'en servir comme faire valoir ?

Il y a peut-être quelque chose qui m'échappe, mais soit tu prends vraiment les gens pour des imbéciles (mais je crois qu'ici, personne n'est dupe), soit tes motivations sont très difficiles à cerner...

Pour ma part, j'ai d'autres projets en cours pour ne pas avoir à utiliser une discussion sur un forum pour me mettre en avant et je n'ai fait que partager une expérience personnelle par rapport à certains projets (propos que tu t'es empressé de critiquer car contraire à ton avis personnel).

-Et la : "Maintenant si ma prose t'ennuie (bien d'autres certaines personnes semblent vraisemblablement l'apprécier), personne ne t'a demandé de rester... " , t'aime pas te faire mousser peut être ? Le mot "humble" n'a pas l'air de faire parti de ton vocabulaire...

Ce que je dis ici, c'est que tu n'es pas le centre du monde et que ton avis n'a pas plus de poids que d'autres personnes ici. Donc question humilité, je ne pense pas avoir de conseils à recevoir de la part de ta petite personne...

Et bien sur, fidèle à ton habitude, tu n'entends que ce qui t'intéresse et déformes les propos dans des tentatives vaines et désespérées de les transformer en arguments de propagande en ta faveur : "ouech vas-y, regardez l'aut' bouffon comment trop qu'y s'la pète avec ses grands airs là" (ceci est une caricature bien sur, ne va surtout pas le prendre au pied de la lettre ! Mais j'avoue cependant éprouver une certaine difficulté à m'abaisser à ton niveau d'argumentation et de langage...).

-Débat HS sur ton but dans une boite...(qui démontre une seule chose, tu as de la chance...)

Ce qui nous arrive dans la vie, c'est parfois une question de chance (ou de malchance, quand le sort s'acharne sur certaines personnes) mais c'est aussi une question d'opportunités.

Et les opportunités, il faut savoir saisir... quitte parfois à prendre des décisions assez difficiles (laisser de côté un environnement qui nous est familier et partir à l'autre bout du monde) ou parfois simplement à faire preuve d'un minimum de bon sens (savoir saisir l'opportunité de faire profil bas lorsqu'une situation ne tourne pas à sont avantage, comme par exemple dans certaines discussions sur un forum public...).

-Et pour ça : "Jusqu'ici on en est encore au stade de la discussion, mais la prochaine étape pour toi c'est la case "modération" (et comme tu peux le constater, tout le détail se trouve déjà dans ce poste, donc ça risque de ne pas prendre très longtemps). À toi de voir...", on dirait tout simplement un flic qui est pressé de rentrer chez lui....

Ce que je fais ici, c'est simplement essayer de te raisonner tant que le dialogue reste (encore ?) possible. Mais puisque tu sembles hermétique à toute forme de dialogue, je crains que tu n'aies à subir les conséquences de ton comportement...

Et bon, puisque tu me compares à un policier, je vais me permettre une petite métaphore :

"Vous êtes en état de modération, tout ce que vous direz pourra et sera retenu contre vous durant le jugement de votre cas. Vous avez le droit à un médiateur. Si vous n'avez pas les moyens de vous en procurer un, un médiateur vous sera commis d'office".

Cordialement,

P.

[erwanlb]

Juste pour re-situer les choses...blablablabla...

J'ai lu que les quelques premières lignes....le post précédent était beaucoup plus interessant

Histoire de pas polluer le sujet, il y a les MP pour ce genre de choses

[pcaboche]

J'ai lu que les quelques premières lignes....le post précédent était beaucoup plus interessant

Je suis tout à fait d'accord avec toi (c'est assez rare pour être signalé) : le poste de _skip est très intéressant et parfaitement argumenté.

Et comme il le fait très justement remarquer, c'est une question de besoin et je n'ai pas le même besoin.

Maintenant que tout le monde est d'accord sur le fait que tout un chacun utilise les outils qui lui conviennent, on peut (enfin ?) clore ce débat stérile que tu entretiens ou tu as encore d'autres attaques personnelles à nous faire partager ?

Histoire de pas polluer le sujet, il y a les MP pour ce genre de choses

Dans ma boite à MP, j'ai pour habitude de ne garder que les sujets intéressants en provenance de personnes de qualité, et ces messages occupent la quasi-totalité de la boite. Ce n'est donc pas la peine de venir polluer ma boite (mais s'il te venait l'idée saugrenue de le faire, tu serais de toute façon assez rapidement bloqué...).

[josuatree]

Nous avons développé une couche d'abstraction en Java (DaoLayer) avec un seul point d'entrée. On peut faire toutes les opérations courantes et même des agrégations sans écrire une seule ligne de SQL. Cette couche est validée par une trentaine de tests unitaires que nous pouvons faire partir à tout moment. Le même code est utilisé pour des Factures, des Clients, etc. On l'utilise dans une dizaine de projets. On peut changer de BD en quelques minutes (aie avec des procédures stockées). Avec cette couche d'accès aux données, la couche métier (worker) ne voit plus rien de ce qu'est une connexion ou du SQL. Elle ne traite que des objets et des listes d'objets. La couche ORM peut aussi être changée (EclipseLink, Hibernate) sans encombre. Bien sûr, il y a eu ici quelques petits problèmes à résoudre, mais actuellement ce n'est que du bonheur. Donc, définitivement OUI aux ORM et avec un framework comme PLAY, ce n'est que du bonheur en plus pour développer des application Web performantes. Salutations.