Dans le secteur bancaire, elles utilisent des procédures stockées pour la logique métier. Leur logique est déplacée dans la db à la place dans la couche logique métier.Procédures stockées et banques
Quelle est la raison pour laquelle les banques insistent pour les procédures stockées?
Cordialement
Les procédures stockées peuvent avoir été là pour 30 ans sur le mainframe. Les langues du client sont venues et ont disparu entre-temps. Quoi qu'il en soit, vous devez définir la "logique applicative": une grande partie de la "logique applicative" se résume à des règles "d'intégrité des données" (telles que "Définir uniquement cette combinaison lorsque l'agrégat des lignes enfants est nul"). être transactionnel et atomique.
connexes:
Simplement, mon code DB survivra votre code client ...
C'est certainement pas le cas de nombreuses banques, j'ai travaillé. Les applications dans les banques sont comme des applications dans une autre société, et la gamme des possibilités de codage presque entièrement dans les procédures stockées, de évitant complètement les procédures stockées dans faveur de quelque chose comme un ORM.
En ce qui concerne pourquoi ils pourraient choisir de mettre de la logique dans les procédures stockées? Parfois, c'est l'endroit sensé pour le faire. Je sais que la foule ALT.NET (ou quel que soit le fanbois NoSQL/ORM pour votre plate-forme de choix) vous fera croire que les procédures stockées sont mauvaises et que les ORM sont la seule solution raisonnable, mais dans le monde réel en construisant de vraies applications avec de vrais exigences différentes, ce n'est pas si simple.