Générateurs de code vs ORM vs procédures stockées

Question

Dans quels domaines chacune de ces architectures logicielles brille-t-elle ou échoue-t-elle?

Quelles exigences clés vous inciteraient à choisir l’une sur l’autre?

Supposons que vous avez des développeurs disponibles qui peuvent faire du bon code orienté objet ainsi que du bon développement de bases de données.

Évitez également les guerres saintes :) Les trois technologies ont leurs avantages et leurs inconvénients, je suis intéressé par le choix du type d'utilisation.

Answer 1

Chacun de ces outils fournit différentes couches d’abstraction, ainsi que des points différents pour modifier le comportement. Ce sont des choix d'architecture, et tous les choix d'architecture dépendent des compromis entre technologie, contrôle et organisation, à la fois de l'application elle-même et de l'environnement où elle sera déployée.

• Si vous avez affaire à une culture dans laquelle les administrateurs de base de données «font la loi», une architecture basée sur une procédure stockée sera plus facile à déployer. Par contre, il peut être très difficile de gérer et de mettre à jour les procédures stockées.

• Les générateurs de code brillent lorsque vous utilisez des langages à typage statique, car vous pouvez détecter les erreurs lors de la compilation plutôt que lors de l'exécution.

• Les ORM sont parfaits pour les outils d'intégration, dans lesquels vous devrez peut-être traiter différents SGBDR et schémas d'installation à installation. Modifiez une carte et votre application, de PeopleSoft sur Oracle à Microsoft Dynamics sur SQL Server.

J'ai vu des applications dans lesquelles Generated Code est utilisé pour l'interface avec les procédures stockées, car les procédures stockées pourraient être modifiées pour contourner les limitations du générateur de code.

En définitive, la seule réponse correcte dépendra du problème que vous essayez de résoudre et de l’environnement dans lequel la solution doit être exécutée. Tout le reste discute de la prononciation correcte de 'pomme de terre'.

Answer 2

Je vais ajouter mes deux cents:

Procédures stockées

• Peut être facilement optimisé
• Règles métier fondamentales abstraites améliorant l'intégrité des données
• Fournissez un bon modèle de sécurité (inutile d'octroyer des autorisations de lecture ou d'écriture à un utilisateur de base de données situé en face)
• Brillez lorsque de nombreuses applications accèdent aux mêmes données

ORM

• Laissez-vous concentrer uniquement sur le domaine et obtenez un résultat plus "pur". approche orientée objet du développement
• Brillez lorsque votre application doit être compatible avec la base de données croisée
• Brillez lorsque votre application est principalement axée sur le comportement plutôt que sur les données

Générateurs de code

• Vous offre des avantages similaires à ceux des ORM, avec des coûts de maintenance plus élevés, mais une meilleure personnalisation.
• Sont généralement supérieurs aux ORM en ce qu’ils ont tendance à échanger des erreurs de compilation contre des erreurs d’exécution, ce qui est généralement à éviter

Answer 3

Je conviens qu'il y a du pour et du contre dans tout et que beaucoup dépend de votre architecture. Cela étant dit, j'essaie d'utiliser les ORM là où c'est logique. La plupart des fonctionnalités sont déjà présentes et permettent généralement d'éviter l'injection SQL (et évitent de réinventer la roue).

Veuillez consulter ces deux autres articles sur le sujet (SQL dynamique vs procédures stockées vs ORM) pour plus d'informations

SQL dynamique par rapport aux procédures stockées
Quel est le meilleur: requêtes ad hoc ou procédures stockées?

ORM vs. procédures stockées
Pourquoi SQL est-il paramétré généré par NHibernate aussi rapidement qu'une procédure stockée?

Answer 4

Les ORM et les générateurs de code sont en quelque sorte d'un côté du champ et les procédures stockées de l'autre. En règle générale, il est plus facile d’utiliser des ORM et des générateurs de code dans les projets greenfield, car vous pouvez personnaliser le schéma de votre base de données en fonction du modèle de domaine que vous créez. Il est beaucoup plus difficile de les utiliser avec des projets hérités, car une fois que le logiciel est écrit avec un "données d'abord" état d'esprit, il est difficile de l'envelopper avec un modèle de domaine.

Cela étant dit, les trois approches ont de la valeur. Les procédures stockées peuvent être plus faciles à optimiser, mais il peut être tentant d'y insérer une logique métier pouvant être répétée dans l'application elle-même. Les ORM fonctionnent bien si votre schéma correspond au concept de l'ORM, mais peuvent être difficiles à personnaliser sinon. Les générateurs de code peuvent constituer un bon compromis, car ils offrent certains des avantages d’un ORM tout en permettant la personnalisation du code généré. Toutefois, si vous prenez l’habitude de modifier le code généré, vous rencontrez alors deux problèmes: devra le modifier à chaque fois que vous le régénérerez.

Il n’existe pas de réponse unique, mais j’ai tendance à privilégier le côté ORM parce que j’estime plus logique de penser avec un état d’esprit centré sur l’objet.

Answer 5

Procédures stockées

• Avantages: encapsule le code d'accès aux données et est indépendant de l'application
• Inconvénients: peut être spécifique au SGBDR et augmenter le temps de développement

ORM

Au moins certains ORM permettent le mappage vers des procédures stockées

• Avantages: Le code d'accès aux données est résumé et permet aux objets d'entité d'être écrits de manière spécifique à un domaine
• Inconvénients: Baisse des performances et capacité de mappage limitée

Génération de code

• Avantages: peut être utilisé pour générer un code basé sur la procédure stockée, un ORM ou une combinaison des deux
• Inconvénients: La couche du générateur de code doit éventuellement être conservée en plus de la compréhension du code généré

Answer 6

Vous avez oublié une option importante qui mérite une catégorie à part: un cadre de cartographie de données hybride tel que iBatis .

Je suis satisfait d'iBatis car il laisse votre code OO rester dans la nature, et votre base de données reste relationnelle, et résout le déséquilibre impédance en ajoutant une troisième abstraction (la couche de mappage entre les objets et les relations) qui est responsable de la cartographie des deux, plutôt que d'essayer de forcer un paradigme à un autre.