Quels sont les arguments pour et contre la logique métier dans les procédures stockées ?
Contre les procédures stockées : la logique d'entreprise dans l'espace de programmation
J'accorde une grande valeur au pouvoir d'expression, et je ne trouve pas que l'espace SQL soit si expressif que ça. Utilisez les meilleurs outils que vous avez en main pour les tâches les plus appropriées. Il est préférable de manipuler la logique et les concepts d'ordre supérieur au niveau le plus élevé. Par conséquent, le stockage et la manipulation de données en masse sont mieux réalisés au niveau du serveur, probablement dans des procédures stockées.
Mais ça dépend. Si plusieurs applications interagissent avec un mécanisme de stockage et que vous voulez vous assurer qu'il conserve son intégrité et son flux de travail, vous devez décharger toute la logique dans le serveur de base de données. Ou alors, préparez-vous à gérer le développement simultané de plusieurs applications.
Pour répondre à votre déclaration sur le développement simultané : plutôt que de stocker la logique métier dans des procédures stockées, pourquoi ne pas cibler un serveur d'applications qui, à son tour, met en œuvre les règles métier ? En utilisant cette méthode, toutes les applications peuvent obtenir la même fonctionnalité avec les avantages de la déduplication du travail.
Je ne sais pas ce que vous entendez par serveur d'application. Donc, dans votre modèle, personne ne parle directement à la base de données mais par une sorte de serveur d'application intermédiaire ?
Droit. En utilisant WCF comme exemple, la couche d'accès aux données serait contenue dans un service WCF, qui transformerait et mettrait en œuvre toutes les règles commerciales nécessaires. À son tour, votre interface utilisateur n'accéderait à rien directement, mais utiliserait des références de service au service WCF, qui fournirait le résultat transformé de manière appropriée. Cela présente également l'avantage de permettre à plusieurs applications d'utiliser les services sans trop de travail. Le service fournit des métadonnées sur ce qu'il renvoie, ainsi que sur les arguments qu'il attend.
Je suis totalement contre. L'une des principales raisons est la première raison invoquée par Erika : il vit à un seul endroit. Vous ne pouvez pas l'intégrer dans le contrôle de la source très facilement. Il est pratiquement impossible d'avoir deux développeurs qui travaillent sur une proc stockée en même temps.
Mon autre grand reproche est que le SQL n'est tout simplement pas très bon pour représenter une logique complexe. Vous n'avez pas de concept de portée, le code a tendance à être copié-collé parce qu'il y a moins de possibilité de réutiliser le code (contrairement à un langage OO).
Vous devez donner aux développeurs l'accès à la base de données pour y développer. Dans de nombreuses organisations où j'ai travaillé, les personnes chargées des données se trouvent dans un monde différent de celui des développeurs, avec des autorisations différentes, etc. Dans ces cas, il serait plus difficile de garder les développeurs en dehors de la base de données.
Je suis de l'école de pensée qui dit que tant que la logique commerciale :
Peu importe que la logique se trouve dans une procédure stockée, dans un niveau intermédiaire J2EE, dans un système expert de clips, ou ailleurs. Quel que soit l'endroit où l'on stocke notre logique d'entreprise, la "loi de conservation de la misère" garantira que quelqu'un dira que c'était une mauvaise idée parce que le composant/référentiel X doit être remplacé par la technologie/méthode Y.
La logique métier peut se trouver dans une couche qui gère la persistance sans être une procédure stockée. L'expression "central" ou "un seul endroit" n'est pas vraiment la bonne lorsqu'il s'agit de décrire des systèmes distribués qui présentent des schémas de cohérence éventuels. De nombreux microservices auront une logique métier liée à leur propre contexte. Le mot "central" ou "un endroit" fonctionne bien lorsqu'il s'agit de décrire des systèmes monolithiques.
@DasithWijes lorsque j'ai répondu à cette question en 2009, nous n'étions pas vraiment concentrés sur les microservices :)
J'ai vu beaucoup de logique d'entreprise dans des procédures stockées dans diverses entreprises et cela n'a JAMAIS été la meilleure solution. Dans TOUS les cas, il n'y avait pas de tests unitaires et le débogage était plus difficile. Cette solution a également entraîné un étalement de la logique métier, en la répartissant sur un trop grand nombre de sources de code. Vous pouvez utiliser des services RESTful ou ajouter des projets en tant qu'externes à d'autres sources de code pour partager la logique métier. La façon de faire de SP a été de loin la pire solution que j'ai vue.
Quelques réflexions : Veuillez noter qu'il s'agit d'une réponse centrée sur Java, mais c'est l'essentiel de mon expérience récente (les 10 dernières années).
(1) Développement simultané par une (grande) équipe de développeurs. Si votre application est suffisamment complexe pour que chaque développeur ne puisse pas mettre en place sa propre version de la base de données (avec des liens, des données de référence, etc...), il est très difficile d'avoir une équipe entière de développeurs travaillant tous sur le même ensemble de paquets PL-SQL (par exemple) en même temps, stockés dans une base de données DEVL partagée ? Dans ce cas, vous êtes coincé (d'après mon expérience) à travailler dans une base de données avec des procédures invalides / une mauvaise correspondance entre le code et les tables lorsque les gens font des changements...
En tant qu'architecte Java, je pense qu'il est beaucoup plus facile pour chaque développeur d'avoir une instance JBoss privée sur son bureau et de travailler facilement sur son propre ensemble de fonctionnalités, et de les intégrer à son propre rythme sans avoir d'impact sur les autres... ce qui m'amène à...
(2) Outils d'intégration continue Bien qu'il existe des "concepts" similaires dans le monde des bases de données, mon expérience m'a montré que la combinaison de (je choisis ici mes favoris actuels) :
L'exécution d'un grand projet à l'aide de tous les outils susmentionnés (outils gratuits) permet de fournir XP aux masses de manière cohérente et facile et d'appliquer des contrôles de qualité à l'ensemble du personnel informatique. Oracle / PL-SQL n'a pas les outils nécessaires.
(3) outils / bibliothèques / etc... Java a accès à un ensemble incroyable de services que les autres plateformes ne peuvent pas toucher - certains gratuits, d'autres payants. Même les plus basiques, comme log4j (oui, ils l'ont pour PL/SQL, mais s'il vous plaît... c'est loin d'être la même chose) permet aux développeurs de créer des logs ajustables de manière flexible qui peuvent être modifiés à la volée (parfait pour le dubugging). Documentation API automatisée (via javadoc). Rapports automatisés sur la couverture des tests unitaires. Des IDEs incroyables (Eclipse) avec débogueurs intégrés / autodéploiement vers des serveurs d'applications. Une API pour s'interfacer avec tous les types de services possibles, des bibliothèques open source pour faire TOUT, et un support à 100% par tous les fournisseurs.
(4) la réutilisation des services. ce que quelqu'un a commenté est vrai. Si vous avez des services lourds règles de gestion fondées sur les données alors vous pouvez argumenter que ceux-ci devraient vivre dans la couche DB. Pourquoi ? Pour éviter que le ou les niveaux intermédiaires n'aient à dupliquer cette logique.
Mais on peut dire la même chose des règles de gestion qui sont ne sont pas axés sur les données ou suffisamment complexes pour que l'OO soit un choix plus naturel. . Si vous placez TOUTE la logique commerciale dans la base de données, elle ne sera disponible que par l'intermédiaire de la base de données.
i
retCode = validateSomeDate(date);
if (retCode == 1) then
evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
sendEmailMsg(....)
else if (retCode == 2) then
performOtherBizLogicStuf(...) //again, may need data, may not need data
triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL
fiJe suis sûr que nous avons tous vu des systèmes écrits comme celui ci-dessus et que nous avons dû les déboguer à deux heures du matin. Il est extrêmement difficile d'avoir une vision cohérente d'un processus complexe lorsque la logique métier est fragmentée entre les différents niveaux, et dans certains cas, la maintenance devient impossible.
"Vous ne pouvez pas l'intégrer dans le contrôle de la source très facilement." - si vous mettez le code qui crée la proc stockée dans un script dont la version est contrôlée, cette objection disparaît. Si vous suivez les idées de base de données agiles de Scott Ambler, c'est exactement ce que vous devriez faire.
Tous les développeurs ne sont pas de bons modélisateurs de données. Je peux penser à des schémas horribles créés par des développeurs qui pensaient qu'une connaissance sommaire de SQL faisait d'eux des experts en bases de données. Je pense qu'il est très utile que les développeurs travaillent avec les administrateurs de bases de données et les modélisateurs de données.
Si une seule application utilise la base de données, je dirais que la logique métier peut apparaître dans le niveau intermédiaire. Si plusieurs applications partagent la base de données, il est peut-être préférable de la placer dans la base de données.
L'architecture SOA offre une solution intermédiaire : les services sont propriétaires de leurs données. Seul le service a accès aux données ; pour accéder aux données, il faut passer par le service. Dans ce cas, il est possible de mettre les règles à n'importe quel endroit.
Les applications vont et viennent, mais les données restent.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Cette question est erronée car elle ne sépare pas la logique métier orientée écriture de la logique métier orientée lecture. Plus je lis les arguments pour et contre la logique dans les procédures stockées, et plus je lis des choses comme CQRS et l'immuabilité, plus je vois que l'optimisation des écritures et des lectures nécessite des classes différentes de logique métier. Qu'est-ce que vous demandez, les deux catégories de logique d'écriture et de lecture ou une seule ?