+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 11 PremièrePremière 123456 ... DernièreDernière
  1. #21
    Rédacteur
    Avatar de benwit
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 1 676
    Points : 3 673
    Points
    3 673

    Par défaut

    Citation Envoyé par SQLpro
    Si le SQL est aussi normé sur les aspect procédures stockée (PSM : Persistant Stored Module). Notamment tout ce qui est gestion des variables, des exceptions, des curseurs....
    Content de l'apprendre

    Citation Envoyé par SQLpro
    (*) Néanmoins, beaucoup d'éditeurs se sont écartés de la norme (Oracle en particulier, SQL Server aussi).
    on aurait du s'en douter

    Citation Envoyé par SQLpro
    Mais c'est le seul moyen d'avoir des objets qui renvoient les mêmes données. Regardez le test que j'ai fait ici : http://sqlpro.developpez.com/cours/s...age=partie1#L3
    Une même requête SQL toute simple donne différents résultats en fonction des différents SGBDR ! Mais ces résultats peuvent devenir identique en masquant les différentes écritures de cette même requête au sein d'une procédure. Et c'est le seul moyen d'être compatible entre différents SGBDR !
    Bon d'accord et suite à ce que tu dis plus haut (*), tu n'utilises alors que ce qui est normé ?


    Citation Envoyé par SQLpro Voir le message
    L'ORM n'apporte pas actuellement cet avantage
    Citation Envoyé par jpouly
    Quand on me dit que c'est plus simple de changer de bases de données avec un ORM, je crois que c'est tout simplement un argument marketing à la c.
    Le fond de ma pensée actuelle est plutôt : Un des objectifs de l'ORM devrait permettre d'apporter une réelle indépendance.
    Je module mes propos parce que dans la pratique, ce n'est pas si transparent (requête jpa qui passe dans oracle mais pas dans mysql, attributs d'objet à renommer car "mots clés oracle", etc ...)

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  2. #22
    Membre à l'essai
    Inscrit en
    mars 2003
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 10
    Points : 10
    Points
    10

    Par défaut

    Un bien beau troll si l'en est

    Le même qui revient tous les ans dans à peu près toutes les langues mais c'est divertissant, continuez ...

  3. #23
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    TOTALEMENT faux ! Regardez les métriques de DULCIAN !
    http://www.dulcian.com/Articles/Thic...ited_final.htm
    Euh... Je suis très anti-ORM aussi et construis la plupart des requêtes complexes avec une bonne stored-procedure (mon bagage SQL et essentiellement PostGreSQL est important, même si ce n'est pas mon principal centre d'intérêt en programmation). Cependant, je dois admettre qu'en terme de développement pur, prendre hibernate, écrire son XML-qui-va-bien ainsi que les jointures directement en java est BIEN plus rapide et nécessite bien moins de tests que la stored-procedure et sa transformation en objet java utilisable (malgré DbUtils qui est un réel avantage lorsqu'on programme comme vous le préconisez).

    Maintenant, on me dira "non" parce que ci ou ça, et parce que c'est écrit dans l'article cité.

    Je persiste en expliquant ceci :
    Avec Hibernate, une fois le mapping créé, nous travaillons directement avec les objets comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    // Assomption : Hibernate est déjà configuré
    try {
      return albums.getLabel().getArtistes().get(0).getNom();
    } catch (HibernateException e) {
      ...
    }
    À l'inverse, une stored procedure:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     -- PgSQL
    CREATE FUNCTION get_premier_artiste_du_label_du_cd AS
    SELECT nom from artiste NATURAL JOIN album ON label_id LIMIT 1
    et de son code java associé
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Connection conn = null;
    PreparedStatement ps = null;
    ResultSet rs = null;
    try {
      conn = ...;
      ps = conn.prepareStatement("execute get_premier_artiste_du_label_du_cd");
      rs = ps.executeQuery();
      return rs.getString(1);
    } finally {
      DbUtils.closeQuietly(conn, ps, rs);
    }
    Lequel mettra davantage de temps à coder et sera plus difficile à tester ? Je crois pas qu'il y a vraiment photo. Et pourtant, je programme de la deuxième manière, qui est bien plus lente, mais qui fournit de meilleures performances.

    Le second en outre est sujet à davantage d'erreurs, spécialement puisqu'il faut une communication certaine entre les deux développeurs qui peut parfois être conflictuelle, et j'ai quelques exemples de procédures mal documentées !

    On me demandera certainement pourquoi mon choix sans ORM, tout simplement pour les performances et le trafic réseau, soit effectivement deux points soulevés dans l'article proposé par SQLPro. Mais je le sais pour avoir fait l'essai quelques fois : je mettrais moins de temps à développer avec Hibernate !

  4. #24
    Membre à l'essai
    Profil pro
    Inscrit en
    octobre 2006
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2006
    Messages : 10
    Points : 10
    Points
    10

    Par défaut ORM - Hibernate / Cayenne

    Voici un petit retour d'expérience sur utilisation d'ORM (hibernate, cayenne) sur plusieurs gros projets.


    Les ORM sont des outils formidable mais très complexes a utiliser.

    Avec hibernate vous pouvez vous passez du SQL en utilisant des requêtes objet (Criteria).

    Concept très en vogue et très apprécié des nouveaux développeurs.

    Gestion des transactions et des sessions simplifiée.

    ----------------------------------------------------------------------------------------------------------------

    Si vous utiliser le générateur de mapping par défaut, vous êtes sur d'avoir des performances décevantes.

    Le temps gagné en développement sera largement dépassé par l'optimisation et le re-modelisation du code. Ce type de Framework est souvent très mal utilisé par les développeurs.

    Si vous développez sans activer les logs SQL vous n'optimiserez pas votre code correctement et donc aurez une application lente.

    Ne pas utiliser de tels frameworks sur des opérations lourdes, se limiter à du CRUD.

    Ces Frameworks sont pour la plupart associé à un cache qui n'est pas la solution miracle, c'est juste une rustine permettant de rééquilibrer la balance en comparaison à un développement classique.

    ----------------------------------------------------------------------------------------------------------------


    Heureusement que la loi de moore existe, pour palier aux développements on SUR gonfle les serveurs. Les ORM ne font pas gagner du temps mais permettent de mieux structurer le code. Ils s'adressent en priorité aux développeurs expérimentés.

  5. #25
    Membre du Club
    Inscrit en
    novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 50
    Points : 54
    Points
    54

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Ce que font tous les SGBDR C/S et généralement en mieux...
    Le session d'Hibernate c'est au niveau client, donc on s'évite le coût d'un voyage via le réseau pour bénéficier du cache. Ensuite on a le cache de niveau 2, toujours au niveau du client qui lui peut se synchroniser via le réseau si l'application est déployée sur plusieurs noeuds.

    La notion de session (niveau 1) est très importante pour comprendre qu'elle peut nous éviter des voyages vers la base de données lors de l'exécution d'une UnitOfWork.

    Sinon je te rejoins sur le point où l'ORM dans sa phase de déploiement doit aller beaucoup plus loin au niveau de son optimisation (création de triggers, de views, etc). Mais cela sera possible si un standard voit le jour à ce niveau là et que les vendors le suivent.

  6. #26
    BsT
    BsT est déconnecté
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    72
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juillet 2004
    Messages : 72
    Points : 83
    Points
    83

    Par défaut

    @dingoth

    Le "getArtistes().get(0) " m'a tué... c'est malheuresement ce que semble reprocher SQLPro (avec un pseudo pareil ... ).

    Il ne faut quand même pas pousser, il y a DB il faut s'en servir.

    Pour moi les ORM sont des aides pour écrire du logiciel (CRUD généralement) : tu ne te paluches pas le code SQL.
    Cependant mal utilisé on obtient des perfs horribles : dirty checking, flushing, mauvaises stratégies de chargement etc... (en SQL si tu oublies un index...)

    Il ne sert à rien de parcourir toute l'arborescence d'objets pour récupérer une information, il convient de passer par une requête ou une procédure stockée.
    (le meilleur des 2 mondes : en fait les ORM c'est le V et SQL le M dans MVC )

    Dans le cadre d'une application métier je comprend l'utilisation d'un ORM, dans le cadre d'une alimentation d'un entrepôt de données je ne le comprendrais pas...

    Enfin c'est perso mais SQLPro je te trouve un peu compact, les matheux comprendront ...

  7. #27
    Invité
    Invité(e)

    Par défaut

    J'ai l'habitude de faire mes propres classe d'acces aux données et de ammping, avec l'habitude, on fait pour 3-4 classes et des relations en meme pas une demi journée et on est sur et certain de nos perfs.

    J'ai essayé NHibernate (version .net de ... hibernate), et j'ai été franchement déçu : au début, c'est tout simple, plus apres on vois des requètes faites dans des boucles, donc tu passe la journée avec NHProf (payant) a trouver d'ou ça viens puis a bricoler un truc pour que ça passe.

    Et franchement je suis 100 fois plus à l'aise en sachant quelle sont mes requètes exécutée, que etre novice sur une techno et risquer de perdre des données vitales.

  8. #28
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    @BsT : Justement, c'est bien le point que je soulève. Un gars qui débute dans les ORM ferait certainement des bourdes aussi grosses que cela et qui bouffent des ressources inutilement. D'ailleurs, j'ai fait seulement une semaine d'Hibernate ; comme quoi... (et je suis vite reparti vers ma thick DB comme SQLPro le préconise).

    Un gars qui débute en SQL fera très certainement moins de fautes de perfs (vraisemblablement il fera une requête du genre "SELECT * from artiste, album WHERE artiste.label_id = album.label_id LIMIT 1"). La bourde SQL devrait être équivalente à celle Java que tu soulèves.

    Pour clarifier ma position, je suis partisan de la Thick DB, mais je n'accepte pas le critère de temps de développement moins élevé avec les DB, surtout venant d'un article non-daté faisant référence à des méthodes de programmation de 2000.

  9. #29
    BsT
    BsT est déconnecté
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    72
    Détails du profil
    Informations personnelles :
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juillet 2004
    Messages : 72
    Points : 83
    Points
    83

    Par défaut

    @dingoth :
    Je connais des personnes expérimentées qui n'ont pas bien appréhendé
    Hibernate.
    C'est vrai que l'impression de facilité gâche l'expérience des ORM, certain ont oublié qu'il y avait une base de données derrière

    Je trouve ta position beaucoup plus saine (plus ouverte) que celle de l'auteur du thread, et malheuresement c'est un prof...

    @Alesque
    Le cache de premier niveau permet bien évidement un gain de vitesse, mais il est surtout la pour assurer la cohérence de ton arborescence d'objets.

    ex (2 chats avec le même propriétaire Petit):

    cat1.getProprietaire().getNom() -> Petit
    cat2.getProprietaire().getNom() -> Petit

    cat1.getProprietaire().setNom("Dupont");
    cat2.getProprietaire().getNom() -> Dupont

    (dans la db il n'y a qu'un enregistrement propriétaire)

  10. #30
    Membre confirmé
    Inscrit en
    juin 2009
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 219
    Points : 456
    Points
    456

    Par défaut

    Les ORM sont ils dangereux ? C'est une question que je me pose depuis 9 mois (le temps de faire un gosse, lol). Je travaille sur projet pour un grand compte, lorsque l'on regarde le temps que met un batch pour traiter toute la volumétrie, pres de 20H sur une machine AIX equipé de 12 processeurs à 4Ghz, 20Go de ram. Voir un traitement qui pendant 20H bouffe toutes les ressources (100%) de la machine, ca fait peur.
    Ce que je trouve intéressant dans des framework tel que hibernate, c'est la partie gestion automatique du cache de données, plus besoin de mettre en place une solution sur le projet. Mais ces frameworks, nécessitent de tres grosses ressources pour de forte volumétrie, JVM 64bit de rigueur.

    Par contre j'aimerais revenir sur les argument suivant:
    - Maintenabilité: Des base de données, tels que oracle offre la posibilité de faire du dev genérique et objet, sur Oracle 10 et 11 on peut meme concevoir un modele de données objet. Il y a bien une raison au fait que ca coute la peau des fesses.
    - Performance: Il est difficile de faire plus rapide qu'une requete directement sur le SGBD, notament grace à la possible utilisation de Hints, et de clause spécifique.
    - Indépendance du SGBD: Si une boite investit dans un outils comme oracle, j'ose espéré qu'elle attende quelques années avant de changer de SGBD histoire d'avoir un retour sur investissement. Du coup l'indépendance du SGBD n'est intéressant que pour les éditeurs de progiciel, je pense que les client finaux et SSII n'y gagnent pas grand chose. De plus, la notion d'indépendance du SGBD empeche d'utiliser des parties optimiser d'un SGBD ou d'un autre

    Je suis assez d'accord avec @SQLpro, sans aller jusqu'a dire que les ORM sont des immondisses. Les ORM apportent des idées que les SGBD auraient dû intégrer depuis belle lurette. Mais ce n'est peut-etre pas la direction à suivre, il faudrait peut-etre chercher à améliorer le concept des SGBD, tel que nous le connaissons aujourd hui.

  11. #31
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 860
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    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 860
    Points : 7 210
    Points
    7 210

    Par défaut

    De mon côté, nous utilisons joyeusement des outils comme cayenne (+ comme un mapper) et le gain de développement est réel.

    Je pense que c'est presque un mythe de vouloir un monde full OO lorsqu'il y a une base de données relationnelle derrière, et c'est peut être là que certains débutants font des erreurs.

    Celle que je vois souvent, c'est par exemple négliger les fonctions aggrégats.
    Commencer à faire des sommes en bouclant sur une collections de "Orders" d'un objet "customer" en ne se rendant pas compte que cela nécessitera le chargement de certaines branches dans le graphe objet alors qu'on peut résoudre ceci efficacement en 1 aller-retour à l'aide d'une SUM en SQL et une ou deux jointures.
    Un autre exemple qui revient souvent, c'est charger une collection d'objet à l'aide d'un select puis ensuite supprimer ses membres un à un au lieu de balancer tout de suite un DELETE en sql.

    Pour éviter ça, je pense qu'il est simplement important de garder un oeil sur le code SQL envoyé par l'ORM à la base de données et ne pas attendre pour s'inquéter lorsqu'on constate que ça ne correspond pas du tout au SQL qu'on écrirait soi-même naturellement (multiples requêtes au lieu de jointures, etc...).

    Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
    Par contre y avoir exceptionnellement recours pour des traitements qui nécessiteraient beaucoup d'aller-retours, c'est tout à fait admis ici. Mais hors de question de faire des Insert et des Update d'une seule ligne avec des procédures stockées.

  12. #32
    Membre à l'essai
    Inscrit en
    mars 2003
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 10
    Points : 10
    Points
    10

    Par défaut

    Citation Envoyé par _skip Voir le message
    Pour éviter ça, je pense qu'il est simplement important de garder un oeil sur le code SQL envoyé par l'ORM à la base de données et ne pas attendre pour s'inquéter lorsqu'on constate que ça ne correspond pas du tout au SQL qu'on écrirait soi-même naturellement (multiples requêtes au lieu de jointures, etc...).

    Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
    Par contre y avoir exceptionnellement recours pour des traitements qui nécessiteraient beaucoup d'aller-retours, c'est tout à fait admis ici. Mais hors de question de faire des Insert et des Update d'une seule ligne avec des procédures stockées.
    Bravo tout est dit : il faut réfléchir ... et analyser ce qui est naturellement produit par l'ORM pour adapter son utilisation !

  13. #33
    Membre confirmé
    Inscrit en
    juin 2009
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 219
    Points : 456
    Points
    456

    Par défaut

    Citation Envoyé par Mektoub Voir le message
    Bravo tout est dit : il faut réfléchir ... et analyser ce qui est naturellement produit par l'ORM pour adapter son utilisation !
    Ca s'appelle de la bidouille, non?

  14. #34
    Membre régulier
    Profil pro
    CHEF DE PROJET
    Inscrit en
    décembre 2004
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : CHEF DE PROJET

    Informations forums :
    Inscription : décembre 2004
    Messages : 96
    Points : 91
    Points
    91

    Par défaut

    Ne faudrait il pas que les éditeurs de SGBD respectent la norme SQL et l'enrichissent si nécessaire ?
    Cela résoudrais le problème de portabilité !

  15. #35
    Expert éminent
    Avatar de neo.51
    Profil pro
    Inscrit en
    avril 2002
    Messages
    2 664
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations forums :
    Inscription : avril 2002
    Messages : 2 664
    Points : 6 480
    Points
    6 480

    Par défaut

    Dans ce cas là ne vaut-il pas mieux utiliser un générateur de code afin de modeler sa DAL aux besoins ?

    Perso dés qu'une applis sort des classiques CRUD je préfère passer par un générateur de code pour modeler ma DAL en fonction de mes besoins parce que sinon utiliser un ORM et à coté coder une partie de l'accès aux données je trouve que ça manque de cohérence et que ça complique la maintenance du code...

  16. #36
    Membre du Club
    Inscrit en
    novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 50
    Points : 54
    Points
    54

    Par défaut

    Citation Envoyé par neo.51 Voir le message
    Dans ce cas là ne vaut-il pas mieux utiliser un générateur de code afin de modeler sa DAL aux besoins ?

    Perso dés qu'une applis sort des classiques CRUD je préfère passer par un générateur de code pour modeler ma DAL en fonction de mes besoins parce que sinon utiliser un ORM et à coté coder une partie de l'accès aux données je trouve que ça manque de cohérence et que ça complique la maintenance du code...
    Quels sont les outils que tu utilises pour générer tes DAL ?

  17. #37
    Provisoirement toléré Avatar de Maximilian
    Profil pro
    Inscrit en
    juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 2 622
    Points : 2 970
    Points
    2 970

    Par défaut

    Les outils d'ORM ne sont évidemment pas des silver bullets. Personne n'a jamais prétendu qu'il fallait leur déléguer aveuglément 100 % des accès aux données.
    Si 95 % des requêtes sont traitées automatiquement par l'ORM, c'est déjà très bien. Pour le reste (requêtes trop lentes ou trop complexes), il est évident qu'il faut passer par du SQL "à la main" ou une optimisation au cas par cas.

    Je pense que gérer l'ensemble de la logique métier dans du code procédural au sein du SGBD serait revenir sur vingt ans de fruits du paradigme objet en matière de génie logiciel. Et aussi se priver de nombreuses pratiques de développement qui fonctionnent en synergie avec l'objet et dont l'efficacité est reconnue :

    - design patterns
    - refactoring
    - test-driven development
    - domain-driven design

    j'en passe et des meilleures.
    Pensez au bouton

  18. #38
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Citation Envoyé par _skip Voir le message
    Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
    Pour maintenir à la fois des procédures stockées et du code java, je vois bien la difficulté que l'on pourrait ressentir. Cependant, elle n'est pas présente. Il suffit de savoir séparer d'une part les données et d'autre part le reste (et pas spécialement la couche de présentation : la coordination entre les systèmes par exemple). La maintenance est relativement aisée, malgré les centaines de procédures stockées et les milliers de classes que nous avons. Si les architectes de l'application font bien leur boulot, pas de souci, tout sera là ou ça doit être et en fonction de la nature du problème, l'endroit d'où il provient sera évident.

  19. #39
    Membre éprouvé Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 1 014
    Points
    1 014

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Si les architectes de l'application font bien leur boulot, pas de souci, tout sera là ou ça doit être et en fonction de la nature du problème, l'endroit d'où il provient sera évident.
    Un code métier n'utilisant que les données d'une BD devra être dans le SGBD (pour éviter les accès multiples), mais si à un moment il a besoin d'une ressource (webservice par exemple) qui n'est pas dans la BD il sera réintégré dans le code classique (hors BD). Donc du coup c'est plus floue de savoir où doit être quoi car ça dépend de si ça utilise une ressource tierce ou pas, pas forcément évident à savoir.

    Pour moi, les serveurs d'applications devraient aussi servir de SGBD (ou l'inverse), ainsi tout serait regroupé.

  20. #40
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Nous avons différentes databases. Pour effectuer une requête d'un de nos clients, nous devons impérativement piocher dans plusieurs de ces bases de données. En outre, nous avons parfois besoin d'un accès à un webservice.

    Pour cela, nous distinguons la transaction relationnelle (de base de données) de la transaction applicative. Généralement et selon le système dans lequel je développe, une transaction applicative regroupe plusieurs transactions relationnelles. Et lorsque nous faisons appel à des web-services, ce n'est qu'une étape de la transaction applicative, complètement indépendante d'une transaction relationnelle. Oui, dans le cadre de l'application que je décris, Java n'a comme rôle que de gérer les transactions applicatives, de faire des appels à des systèmes tiers (y compris bases de données et web-services) et de formatter la réponse pour le système appelant.

    Nous nous basons énormément sur des diagrammes. Le premier et le plus important est celui de l'intéraction entre les systèmes : cette application se connecte à tel système et tel système. C'est tout. D'autres diagrammes sont des sortes de zoom et disent dans quel contexte un processus se connecte à tel ou tel système. (Une transaction applicative est une exécution d'un processus, pour que vous compreniez mon vocabulaire ; on pourrait dire processus = classe et transaction = instance.)

    Ceci est parfaitement résumé dans mon message précédent : « si les architectes de l'application font bien leur boulot, pas de souci. »

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, 11h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 19h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 08h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 08h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 23/11/2008, 23h13

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