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

ORM PHP Discussion :

Question sur l'utilisation de la méthode Merise avec un ORM


Sujet :

ORM PHP

  1. #1
    Membre éclairé
    Homme Profil pro
    Développeur backend junior - Symfony
    Inscrit en
    janvier 2018
    Messages
    325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : Développeur backend junior - Symfony
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2018
    Messages : 325
    Points : 784
    Points
    784
    Par défaut Question sur l'utilisation de la méthode Merise avec un ORM
    Bonjour à tous,

    Je me permets de de venir à vous pour vous demander un avis sur une question qui me taraude.

    Jeune développeur backend faisant sa bosse sur Symfony et utilisant, à tord à et travers car on me l'impose au travail, Doctrine, je désirai savoir une chose : partisan sans faille de la méthode MERISE (MCD & MLD) et préférant l'optimisation de la base de données avant l'optimisation de l'application (partie base de données), je me bats pour qu'on utilise cette méthode au travail avant pour dans le cadre de la problématique d'une bonne analyse et conception.

    Malheureusement, le lead developer de l'entreprise où je suis estime que c'est la vision objet qui prime alors que, durant mes années d'étude (dont une avec des professionnels uniquement), on nous a clairement expliqué que si une application à une base de données, elle prime et doit être réalisée avant la vision applicative.

    Qu'en pensez-vous ?

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 437
    Points
    2 437
    Par défaut
    À partir du moment où on utilise Doctrine ORM (je précise bien ORM), on sacrifie déjà l'optimisation de la BDD au profit de la rapidité et la simplicité de développement.

    La vraie question est quelle est la priorité? Le plus souvent, la priorité est d'obtenir très vite un "truc qui marche", çad un MVP, puis de faire des multiples itérations après. Les objets peuvent donc constamment changer au cours du refactoring, et dépenser du temps pour une conception parfaite de la BDD est une perte, puisque les schémas évoluent très vite. Et souvent au début de la vie de l'application, l'optimisation (ou même le type) de BDD n'est pas important. Dans ces cas, Doctrine ORM (ou n'importe quel autre ORM) aide énormément.

    Il est donc dans ce cas préférable d'optimiser la BDD plus tard, lorsque le codebase de l'application est stable et lorsqu'on voit que la BDD est le goulot d'étranglement de l'application (soit en termes d'utilisation, soit en terme de développement).

    Maintenant, si on a un temps infini, les choses peuvent être différentes.

  3. #3
    Membre éclairé
    Homme Profil pro
    Développeur backend junior - Symfony
    Inscrit en
    janvier 2018
    Messages
    325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : Développeur backend junior - Symfony
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2018
    Messages : 325
    Points : 784
    Points
    784
    Par défaut
    Je comprends mieux certaines choses de ce fait mais j'avoue que, si le cahier des charges est bien fait et que le client a bien spécifié ses désirs en plus d'avoir un responsable métier présent dans le processus de développement, l'analyse et conception, base de données comme couche applicative, ne doivent, en théorie, que très peu changer de par le fait que de par ces éléments, nous obtenions un résultat concret et qui bougera très peu.

    Après, si la question aujourd'hui est de produire un code dégueulasse, non standard, impossible ou difficile à maintenir mais en plus truffé d’ineptie, je ne vois alors pas l'intérêt d'entretenir dans certaines formations comme le BTS SIO (dont je suis un ancien étudiant) et la licence professionnelle que j'ai réalisé les principes de développement et d'analyse et conception si tout le monde s'en fou.

    Je sais pertinemment que c'est un débat sans fin mais j'avoue que l'avis d'autres personnes m'aideraient car j'ai du mal à me rendre compte.

  4. #4
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 437
    Points
    2 437
    Par défaut
    si le cahier des charges est bien fait et que le client a bien spécifié ses désirs
    Dans le web, que ce soit des sites, des API ou des apps, j'ai bien peur que ça soit une chose rare, à moins qu'on parle de site vitrine. Ce n'est pas forcément que le client ait mal défini ses besoins (même si ça arrive), mais les choses évoluent si vite que les besoins, les technologies et les usages changent.

    Le Waterfall marche peut-être pour des gros projets enterprise (ERP etc...) où le domain est connu et maîtrisé, rien ne changera dans les mois et années à venir, et tout est planifiable. Dans le web, c'est agile et itérations.

    Il n'est absolument pas question de maintenir du code déguelasse, je ne sais pas où tu travailles mais ce n'est pas du tout ça. L'objectif c'est d'avoir un code suffisamment robuste pour pouvoir éliminer des fonctionnalités lorsqu'on se rend compte que personne ne les utilise, et d'en ajouter des nouvelles qui correspondent à un besoin. Cela suppose de préserver une certaine flexibilité du schéma de la BDD, et c'est entre autres ce qui a poussé beaucoup de start-ups à utiliser des NoSQL qui accordent une très grande liberté (au détriment de l'ACIDité). Bref, la BDD n'est pas vraiment la première priorité dans ce cas.

    un résultat concret et qui bougera très peu.
    Le problème est que ce résultat bougera, et il doit bouger! Contrairement à un logiciel où tu peux sortir une version tous les 2-3 ans, une application web (ou une API, ou une appli mobile) vit et change constamment, sauf si elle est vraiment très basique.

  5. #5
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    6 389
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 389
    Points : 18 566
    Points
    18 566
    Par défaut
    Citation Envoyé par NBoulfroy Voir le message
    si le cahier des charges est bien fait et que le client a bien spécifié ses désirs
    Ahhhh la douce innocence du tout jeune développeur
    Quand déjà le cahier des charges existe tu peux t'estimer heureux , alors qu'il soit bien fait c'est juste une utopie.
    Ah oui et le client qui spécifie ses désir et qui s'y tient c'est pareil ca n'existe pas.

    Après, si la question aujourd'hui est de produire un code dégueulasse, non standard, impossible ou difficile à maintenir mais en plus truffé d’ineptie, je ne vois alors pas l'intérêt d'entretenir dans certaines formations comme le BTS SIO (dont je suis un ancien étudiant) et la licence professionnelle que j'ai réalisé les principes de développement et d'analyse et conception si tout le monde s'en fou.
    Comme le dit Tsilefy à part a travailler dans l'open source ce qui prime c'est les délais et donc le coût. Et donc inévitablement il arrive qu'on fasse les choses pas dans les règles de l'art pour ces raisons. Il faut essayer tant que possible de le limiter mais ça arrive.


    on nous a clairement expliqué que si une application à une base de données, elle prime et doit être réalisée avant la vision applicative
    Je dirais que ça dépend de la situation.
    La base de données est elle là pour servir l'applicatif ? Du genre gestion d'utilisateur, de droit , etc ... Dans ce cas il est évident qu'il faut penser la base pour le code. Et les optimisation de la bdd sont secondaire.
    Ou alors la base de données est le coeur du projet , par exemple un ERP. Toutes les données et tous le métier repose sur cette base => dans ce cas là on va plutôt adapter l'applicatif à la base et effectivement dans ce cas les optimisation de bdd on du sens.

    Les optimisations de bdd c'est comme le code , faut que ce soit significatif. Refactorer une bdd pour gagner 3ms sur une requête c'est du vent. Par contre si je peux gagner quelques Go d'espace ou quelques minutes sur une requêtes , là oui ça vaut le coup.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

Discussions similaires

  1. Question sur l'utilisation de wget
    Par berry dans le forum Réseau
    Réponses: 7
    Dernier message: 24/05/2007, 22h46
  2. Question sur l'utilisation du popupMenu
    Par Jayceblaster dans le forum Delphi
    Réponses: 2
    Dernier message: 25/07/2006, 10h59
  3. question sur l'utilisation d'une listBox
    Par Mickey.jet dans le forum Delphi
    Réponses: 3
    Dernier message: 02/06/2006, 17h57
  4. Question sur l'utilisation du mot réservé static
    Par flash2590 dans le forum Langage
    Réponses: 4
    Dernier message: 10/04/2006, 00h20
  5. [Framework] Questions sur l'utilisation de spring
    Par mlequim dans le forum Spring
    Réponses: 10
    Dernier message: 01/02/2006, 15h27

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