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

Design Patterns Discussion :

L'utilisation d'une ORM rend il la fabrique abstraite inutile?


Sujet :

Design Patterns

  1. #1
    Membre actif Avatar de 3logy
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2007
    Messages
    280
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Août 2007
    Messages : 280
    Points : 222
    Points
    222
    Par défaut L'utilisation d'une ORM rend il la fabrique abstraite inutile?
    Salut a tous,

    j'ai actuellement une Discussion avec un collégue. Nous sommes entrain d' écrire une Framework Java from scratch. Actuellement il se porte le probleme de la creation des users pour notre plateforme. Mon collégue affirme que l'utilisation d'une ORM rendrais non seulement la tâche plus rapide mais aussi plus facile. Moi je suis plûtot de l'avis que même en utilisant un ORM, ceci n'exclut pas le clean code donc le Design Pattern comme la Fabrique Abstraite.

    Qu'est que vous en pensez faudrait il mieux utiliser des ORMs ou bien l'utilisation de celle ci n'empêche pas l'utilisation des Creational Patterns?

  2. #2
    Futur Membre du Club
    Homme Profil pro
    Consultant ERP
    Inscrit en
    Mai 2014
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2014
    Messages : 11
    Points : 5
    Points
    5
    Par défaut
    Hello,

    perso, je vois pas de lien.

    Ton ORM est une couche de modélisation de ta base de données avec tous les accesseurs pour requêter en base sans utiliser la moindre SQL Explicitement.
    Ton Factory s'occupe de créér des instances de classes.

    Une fois tes instances créées, si elles ont besoin d'agir sur la BDD elles le feront au travers de ton ORM.

    Cdlt.

  3. #3
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    Bonjour,

    Tout dépends si vous souhaitez développer un framework performant ou si vous souhaitez développer un framework facilement et vite. Si vous souhaitez la performance, je répondrais ni l'un ni l'autre, et si vous souhaitez un compromis entre les deux, je dirais que l'ORM est le pire.

    Je reste à votre disposition pour un complément d'information éventuel.

    Cordialement.

  4. #4
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    Bonjour,

    Je vois que je me suis pris un vote négatif, peut-être l'ai-je mérité, je vais donc argumenter et expliquer le pourquoi de ma réponse.
    Pour garder les performances, il faut toujours communiquer avec la source principale de données de l'application en mode natif, chose qui est impossible si on utilise ces outils dans un contexte d'abstraction pure. C'est d'ailleurs ainsi que SSMS a été développé : on modélise en objet la DB à administrer mais on communique avec elle uniquement en natif. Les requêtes sont donc non standardisées et non générique mais uniquement spécifiques au SGBDR ciblé selon la tâche à accomplir.

    Or ce n'est pas du tout ainsi que des outils comme les ORM sont utilisés dans les frameworks web actuels, mais plutôt comme outil d'abstraction pour faire de l'abstraction et requêter de la même manière SQL Server et postgreSQL par exemple (standardisation de la couche d'accès aux données). La fabrique de classe dans ce sens ce rapproche plus de la bonne pratique car elle laisse la place plus aisément à de l'implémentation spécifique du SGBDR cible.

    Mon conseil est d'utiliser l'ORM que dans un contexte de migration de données ou alors éventuellement dans le contexte d'un module d'import/export de données, et la fabrique de classe pour communiquer avec la source principale de données de votre applicatif à la seule condition de laisser la place dans votre modèle à une implémentation native au SGBDR ciblé au niveau de la couche métier.

    ++

Discussions similaires

  1. [Débutant(e)] JSP utilisation static....une autre
    Par tcgenrecom dans le forum Servlets/JSP
    Réponses: 2
    Dernier message: 01/03/2004, 16h27
  2. utilisation d'une variable globale
    Par ZZ dans le forum ASP
    Réponses: 3
    Dernier message: 03/12/2003, 20h11
  3. Utilisation d'une variable sur plusieurs unités
    Par Yamaneko dans le forum Langage
    Réponses: 2
    Dernier message: 05/06/2003, 12h23
  4. Utilisation d'une dll écrite en delphi 5 dans VB6
    Par Jean-Louis dans le forum Langage
    Réponses: 4
    Dernier message: 05/08/2002, 10h19
  5. Réponses: 4
    Dernier message: 05/06/2002, 15h35

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