Logique d'entreprise dans la base de données ou le code?
En tant qu'ingénieur logiciel, j'ai un fort parti pris pour l'écriture de la logique métier dans la couche application, tout en s'appuyant généralement sur la base de données pour un peu plus que les opérations CRUD (Create Retrieve Update and Delete). D'un autre côté, j'ai parcouru des applications (généralement des anciennes) où une grande partie de la logique métier a été écrite dans des procédures stockées, donc il y a des gens qui préfèrent écrire la logique métier dans la couche de base de données.
Pour les personnes qui ont et/ou apprécient la logique métier écrite/écrite dans une procédure stockée, quelles étaient/sont vos raisons d'utiliser cette méthode?
J'essaie de limiter sérieusement ma logique métier dans la base de données aux seuls procs qui doivent faire beaucoup de requêtes et de mises à jour pour effectuer une seule opération d'application. Certains peuvent affirmer que même cela devrait être dans l'application, mais j'aime garder le IO bas si je le peux).
Les bases de données sont idéales pour CRUD, mais si elles sont gonflées de logique:
- Cela devient déroutant où la logique est,
- En règle générale, les bases de données sont un silo et ne s'adaptent pas horizontalement aussi bien que les serveurs d'applications.
- t_sql/PLsql est difficile à lire et de nature procédurale
- Vous perdez tous les avantages d'OOAD.
Dans la mesure du possible, conservez votre logique métier dans l'environnement qui est le plus testable et déboguable. Il existe des raisons valables de stocker la logique métier dans la base de données dans les réponses existantes d'autres personnes, mais elles sont presque toujours largement compensées par cela.
Limiter au mieux la logique métier à la couche application. Les concepteurs de bases de données professionnels expérimentés l'autorisent rarement sur leurs systèmes. La base de données doit avoir des contraintes et des déclencheurs et des proc stockés pour aider à définir comment les données de n'importe quelle source y entreront.
Si la base de données doit maintenir son intégrité et garantir que toutes les sources de nouvelles données ou modifications de données respectent les règles, la base de données est l'endroit idéal pour mettre la logique requise. Mettre la couche application est un cauchemar de données qui attend de se produire. Les bases de données n'obtiennent pas d'informations uniquement à partir d'une seule application. La logique métier dans l'application est souvent involontairement contournée par les importations (supposons que vous ayez un nouveau client qui voulait que ses anciennes données historiques soient importées dans votre système ou un grand nombre d'enregistrements cibles, personne ne va entrer un million de cibles possibles via l'interface, cela se produira lors d'une importation.) Il est également contourné par les modifications apportées via la fenêtre de requête pour résoudre les problèmes ponctuels (des choses comme l'augmentation du prix de tous les produits de 10%). Si vous avez une logique de couche d'application qui aurait dû être appliquée à la modification des données, elle ne le sera pas. Maintenant, il est correct de le mettre également dans la couche application, cela n'a aucun sens d'envoyer de mauvaises données à la base de données et de gaspiller la bande passante du réseau, mais ne pas le mettre dans la base de données entraînera tôt ou tard des problèmes de données.
Une autre raison de conserver tout cela dans la base de données tient à la possibilité que les utilisateurs commettent une fraude. Si vous placez toute votre logique dans la couche application, vous devez accorder aux utilisateurs un accès direct aux tables. Si vous encapsulez toute votre logique dans des proc stockés, ils peuvent se limiter à faire uniquement ce que les proc stockés le permettent et rien d'autre. Je n'envisagerais pas d'autoriser tout type d'accès par les utilisateurs à une base de données qui stocke des dossiers financiers ou des informations personnelles (comme les dossiers de santé) car je ne permettrais à personne, à l'exception de quelques dbas, d'accéder directement aux dossiers de production de quelque manière que ce soit . Plus de fraudes sont commises que de nombreux développeurs ne le pensent et presque aucun d'entre eux n'envisage la possibilité dans leur conception.
Si vous devez importer une grande quantité de données, le fait de passer par une couche d'accès aux données peut ralentir l'importation vers une analyse, car cela ne prend pas en compte les opérations basées sur des ensembles que les bases de données sont conçues pour gérer.
Votre utilisation du terme "logique métier" est plutôt vague.
Il peut être interprété comme signifiant inclure l'application de contraintes sur les données (alias "règles métier"). L'application de ces dispositions appartient sans équivoque aux dbms, point final.
Cela peut aussi être interprété comme signifiant inclure des choses comme "si un nouveau client arrive, alors dans une semaine nous lui envoyons une lettre de bienvenue." Essayer de pousser des choses comme ça dans la couche de données est probablement une grosse erreur. Dans de tels cas, le pilote pour "créer une nouvelle lettre de bienvenue" devrait probablement être l'application qui déclenche également l'insertion de la nouvelle ligne client. Imaginez chaque nouvelle insertion de ligne de base de données déclenchant une nouvelle lettre de bienvenue, puis soudain nous reprenons une autre entreprise et nous devons intégrer les clients de cette entreprise dans notre propre base de données ... Aïe.
Nous faisons beaucoup de traitement dans le niveau DB, le cas échéant. Il y a beaucoup d'opérations sur lesquelles vous ne voudriez pas retirer de grands ensembles de données au niveau de l'application pour effectuer une analyse. C'est également un déploiement plus facile pour nous - un seul point par rapport à la mise à jour des applications à tous les points d'installation. Mais cela dépend beaucoup de votre application et de ce qu'elle fait; il n'y a pas de bonne réponse ici.
Je dirais que si la `` logique métier '' signifie le flux d'application, le contrôle des utilisateurs, les opérations chronométrées et généralement `` faire des affaires '', alors cela devrait être dans la couche application. Mais si cela signifie vous assurer que peu importe la façon dont vous fouillez dans les données, cela a toujours du sens et est un ensemble sensible et non conflictuel, alors les vérifications pour appliquer ces règles vont dans la base de données, absolument, pas de questions. Il existe toujours de nombreuses façons de pousser des données dans la base de données et de les manipuler une fois qu'elles sont là. Toutes ces méthodes n'ont pas intégré de "logique métier". Vous trouverez une session SQL dans une base de données via une fenêtre DOS sur un appel au support à 3h du matin est très libéral dans ce qu'il permet par exemple! Si la logique n'est pas dans la base de données pour s'assurer que TOUS les changements de données ont un sens, vous pouvez parier avec certitude que les données seront très, très foirées au fil du temps. Et puisqu'un système n'a que la valeur des données qu'il détient, cela permet un retour sur investissement beaucoup plus faible.
À quelques reprises, j'ai mis la "logique" dans les sprocs parce que le CRUD peut se produire à plusieurs endroits. Par "logique", je dois dire que ce n'est pas vraiment de la logique métier mais davantage une "logique d'intégrité". Ce pourrait être la même chose - un nettoyage pourrait être nécessaire si quelque chose est supprimé ou mis à jour d'une certaine manière, et si cette suppression ou cette mise à jour peut se produire à partir de plusieurs outils avec des bases de code différentes, il était logique de le mettre dans le processus qu'ils tous utilisés.
De plus, la "ligne de logique métier" est parfois assez floue. Prenons l'exemple des rapports - ils peuvent s'appuyer sur des procédures stockées ou des vues qui encapsulent des `` intelligences '' sur ce que le schéma signifie pour l'entreprise. Combien de fois avez-vous vu des déclarations CASE et autres qui "font des choses" en fonction des valeurs des colonnes ou d'autres critiques? Peut être interprété comme une logique métier et pourtant, il appartient probablement à la base de données où il peut être optimisé, etc.
Deux bonnes raisons de mettre la logique métier dans la base de données sont:
- Il sécurise votre logique et vos données contre des applications supplémentaires qui peuvent accéder à la base de données qui n'implémentent pas de logique similaire.
- Les conceptions de base de données survivent généralement à la couche application et réduisent le travail nécessaire lorsque vous passez à de nouvelles technologies côté client.
Vous trouverez souvent la logique métier au niveau de la couche de base de données, car il peut souvent être plus rapide d'effectuer une modification et de se déployer. Je pense que souvent, les meilleures intentions ne sont pas de mettre la logique là-bas, mais en raison de la facilité de déploiement, elle finit là.
Je travaille pour une entreprise de type financier où certaines règles sont appliquées par les États, et ces règles et leurs calculs sont susceptibles de changer presque quotidiennement, voire sûrement chaque semaine. Cela étant, il était plus logique de déplacer des parties de la logique traitant des calculs vers la base de données; où un changement peut être testé et appliqué sans avoir à recompiler et redistribuer une application, ce qui est impossible à faire quotidiennement sans perturber les activités. Le processus stocké est testé, approuvé, appliqué et l'utilisateur final n'est pas plus sage. Avec le passage aux applications Web, la dépendance à l'égard du déplacement de la logique vers la base de données est moindre mais toujours présente. Même les applications Web (selon la langue) doivent être compilées et publiées sur le site, ce qui pourrait entraîner des temps d'arrêt.
Parfois, la logique métier est trop lente pour s'exécuter sur la couche d'application. Cela est particulièrement vrai sur les anciens systèmes où la puissance et la bande passante du client étaient plus limitées.
La principale raison d'utiliser la base de données pour effectuer le travail est que vous disposez d'un seul point de contrôle. Souvent, les développeurs d'applications réutilisent ou réécrivent des fragments de code dans différentes parties de l'application. Même en supposant que tout cela fonctionne exactement de la même manière (ce qui est douteux), lorsque la logique métier change, l'application doit être revue, recodée, recompilée. À moins que les paramètres ne changent, cela ne serait pas nécessaire lorsque la logique métier est stockée uniquement dans la base de données.
Ma préférence est de garder toute logique métier compliquée hors de la base de données, simplement à des fins de maintenance. Si je reçois un appel à 2 heures du matin, je préfère déboguer mon code d'application que d'essayer de parcourir les scripts de base de données.
La principale raison pour laquelle je mettais BL dans des proc stockés dans le passé est que les transactions étaient plus faciles dans la base de données.
Si les déploiements sont difficiles pour votre application et que vous n'avez pas de serveur d'applications, la modification du BL dans les procédures stockées est le moyen le plus efficace de déployer un changement.
Je pense que spécialement pour les applications plus anciennes sur lesquelles je travaille (bancaire) où la logique Bussiness est énorme, il est presque impossible d'exécuter toutes ces logiques métier dans la couche application, et c'est également un grand succès lorsque nous mettons cette logique dans la couche application où le nombre d'extractions vers la base de données est supérieur, entraîne une utilisation plus importante des ressources (davantage d'objets Java si elle est effectuée dans la couche Java) et des problèmes de réseau, et oubliez les performances.
Je suis dans une équipe pour construire et maintenir un système financier assez important, et je ne trouve aucun moyen de mettre la logique dans la couche application pour des actions qui affectent ou obtiennent des contraintes de dizaines de milliers d'enregistrements.
Outre le problème de performances, si des erreurs se produisent, la rectification d'une procédure stockée est beaucoup plus rapide que le débogage de l'application, la correction, la recompilation, le redéploiement du code avec un temps d'arrêt plus long