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

Autres Discussion :

couche métier intégrée à Orcale


Sujet :

Autres

  1. #1
    Candidat au Club
    Profil pro
    Inscrit en
    juin 2004
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2004
    Messages : 2
    Points : 2
    Points
    2
    Par défaut couche métier intégrée à Orcale
    Bonjour,

    je viens d’intégrer une société qui utilise du Delphi 7 couplé à Oracle pour son application de gestion.
    Leur particularité est de ne pas utiliser de classe mappée à la base de donnée, Delphi n'a aucune connaissance de la base, la couche métier est intégrée dans Oracle par du Pl-sql.
    Je ne sais pas si je m'exprime bien mais pour donner une exemple, il n'y a pas de classe Personne dans Delphi mais une procédure qui va appeler directement une fonction Oracle qui manipulera la table Personne.

    Cette construction me dérange et je souhaiterais avoir votre avis sur le sujet.
    J'ai déjà signalé cette particularité au responsable informatique en lui signifiant qu'avec cette construction ils ne pourrait jamais travailler avec une base de donnée externe sur laquelle ils n'auraient pas la main mais la possibilité de pouvoir changer facilement IDE lui semble plus importante.

    Je ne suis pas une spécialiste en architecture n tiers c'est pourquoi si vous pouviez me donner votre avis, cette architecture est elle bonne ou mes craintes sont elles fondées ? je manque d'argument

    Merci pour votre aide

    Galie

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Bienvenue dans le monde du legacy. C'était une approche courante il y a plus d'une dizaine d'années mais elle est un peu tombée en désuétude. Je ne vais pas refaire le match, une recherche Google te permettra de déterrer les flamewars qui ont eu lieu entre pro et anti procédures stockées.

    Pour moi le problème principal du code métier dans des SP n'est pas tant de ne pas pouvoir changer de SGBD mais qu'on se prive de toutes les facilités fournies par un IDE moderne en termes de navigation dans les sources, refactoring, outils de productivité, tests unitaires, debugging avancé, génération de code...

    Fixer le code business dans la base de données pour avoir le loisir de changer le langage au-dessus était peut-être une approche valide il y a 10 ans, mais le sens de l'histoire ne lui a pas donné raison. Aujourd'hui, la partie programmation des SGBD évolue peu et elles sont attaquées de toutes parts par des approches plus légères (NoSQL...) qui se contentent d'être des stockages persistants très efficaces sans chercher à faire le café et le ménage. D'autre part, il y a un boom de la diversité des langages, des approches de programmation, des environnements de développement, de leur intégration avec les environnements de build, d'ALM, etc. alors que les langages genre PL/SQL ou T-SQL sont restés essentiellement procéduraux avec un outillage autour qui a peu évolué. Aujourd'hui, un développeur qui ne fait que du PL/SQL aura toutes les chances d'atterrir sur un projet legacy et quasiment aucune de travailler sur un produit greenfield ou récent.

    Une transition progressive vers une architecture plus moderne est possible, mais il est souvent difficile de convaincre des décideurs qui voient une application qui marche et ne mesurent pas la nécessité de la faire évoluer. Jouer sur des métriques de temps de résolution de bugs et de réalisation d'évolution peut être une approche, mais si tout le système d'information est conçu de cette manière, le manque de point de comparaison va empêcher de débloquer les choses. Malheureusement, il faut souvent arriver à des extrémités comme un énorme gaspillage d'argent et de temps sur une application en fin de vie pour que tout le monde comprenne qu'il aurait fallu réagir avant...

Discussions similaires

  1. Architecture couche métier <-> couche présentation
    Par bozo614 dans le forum Visual C++
    Réponses: 7
    Dernier message: 22/11/2007, 17h11
  2. [EJB] Architecture couche métier + packaging
    Par st0ne dans le forum Java EE
    Réponses: 2
    Dernier message: 26/10/2007, 10h57
  3. Relation entre EJB, couche métiers, JSP et servlet
    Par infinity21 dans le forum Servlets/JSP
    Réponses: 13
    Dernier message: 05/03/2007, 23h50
  4. Organisation Couche métier
    Par tatemilio2 dans le forum Hibernate
    Réponses: 1
    Dernier message: 08/09/2006, 14h29
  5. Couche métier = forcement EJB ?
    Par jothi35 dans le forum Java EE
    Réponses: 9
    Dernier message: 14/09/2004, 16h58

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