Que ce soit pour mettre la logique métier dans la procédure stockée ou non?

21

Il y a toujours un débat sur le sujet - "Faut-il mettre la logique métier dans la procédure stockée ou pas?". Si nous décidons de ne pas utiliser l'outil ORM et de ne pas mettre la logique métier dans la procédure stockée, alors où devrions-nous mettre la logique métier?

Dans mes applications précédentes, j'ai toujours préféré mettre toute la logique métier dans les procédures stockées uniquement. Ensuite, à partir du code .NET, j'appelle ces procédures stockées à l'aide de blocs d'application d'accès aux données. SQLHelper etc. Mais cela ne peut pas être le scénario tout le temps. J'ai donc fait quelques recherches sur Google mais j'ai fini dans la confusion .......

Des suggestions ...?

c# .net sql

— Pravin Patil
source

Je suis biaisé -> Procs stockés toujours. Mais alors je suis partial. Oubliez la programmation Agile, la triste réalité est que dans le monde des affaires, les changements se produisent toujours de manière ponctuelle et doivent être effectués "immédiatement". Les procédures stockées le permettent. C'est un épargnant de vie. Essayer de faire de telles modifications via la base de code ne serait pas faisable.

— Darknight

4

@Darknight, dépend fortement de votre plate-forme et de votre architecture pour faire une telle déclaration. Je ne vois pas pourquoi le déploiement d'une procédure stockée dans une base de données prend beaucoup moins de temps que, par exemple, l'exécution d'un script de génération et de déploiement pour créer un nouveau fichier WAR, le déployer et redémarrer le serveur d'applications.

— maple_shaft

7

Procédures stockées - la fosse septique de l'informatique.

— Mongus Pong

1

Procédures stockées - juste un autre outil comme les autres.

— sam yi

15

J'adopterais une approche pragmatique - historiquement, le principal `` avantage '' de conserver la logique métier dans les processus stockés est pour des raisons de performances (architecture à 2,5 niveaux), tandis que la séparation de la logique métier en un niveau BLL (niveau 3 / N) est généralement plus propre qu'un perspective de maintenance, et plus facile à tester (Mock / Stub sur l'accès aux données).

Cependant, étant donné que les ORMS .NET compatibles LINQ tels que LINQ2SQL, EF et NHibernate créent désormais des requêtes SQL paramétrées, où les plans de requête peuvent être mis en cache, sont échappés pour l'injection SQL, etc., je suppose que le passage à une architecture de niveau 3 / N est plus convaincant que jamais, et la plupart des SPROC (en particulier ceux centrés sur les requêtes) peuvent être évités. Les modèles de référentiel dans .NET exposent généralement les paramètres de l'arborescence des expressions IQueryable / accept, permettant un accès sécurisé mais flexible à vos tables. (Personnellement, dans les architectures de type SOA, je n'exposerais pas IQueryable au-delà du BLL, c'est-à-dire que vos niveaux de service et de présentation devraient fonctionner avec un ensemble de méthodes bien défini. La raison en est qu'autrement, vous ne pourrez jamais tester complètement votre système et vous aurez gagné ''

Cependant, dans un système de taille décente, il y aura toujours quelques exceptions, où un morceau de code très intensif en données devra peut-être encore être écrit en tant que Proc stocké pour des raisons de performances. Dans ces cas, je conserverais le SPROC et exposerais le SPROC via l'ORM, mais j'exposerais toujours la fonction comme méthode d'intercommunication sur votre BLL.

— StuartLC
source

1

+1 pour faciliter l'écriture de tests unitaires au niveau de l'application, mais les cadres de tests unitaires de base de données automatisés ont parcouru un long chemin.

— maple_shaft

14

En tant que développeur Java, ma préférence était de mettre la logique métier dans le BLL (contrôle de source agréable et facile, familiarité, etc., etc.).

Cependant, après avoir travaillé pour une grande entreprise avec de nombreuses applications distribuées utilisant différentes technologies (C #, Java, Pick (ne demandez pas)), un avantage significatif de l'utilisation des procédures stockées est devenu apparent:

Les procédures stockées peuvent être partagées entre différentes applications .

— NimChimpsky
source

Très bon point

— NoChance

1

C'est très vrai, et nous l'utilisons à bon escient dans notre environnement. Cependant, le partage de code à l'aide de la couche de données m'a toujours semblé un peu dangereux. Si vous avez plusieurs consommateurs d'une pièce / logique donnée, je préfère mettre un service devant lui plutôt que d'avoir plusieurs consommateurs de la même base de données.

— RationalGeek

2

Si vous divisez votre gestion de données en bibliothèques, ces bibliothèques pourraient également être théoriquement partagées entre différentes applications ...

— glenatron

2

Je suis d'accord en partie. Toutes ces technologies accèdent directement à la base de données; vous utilisez donc des procédures stockées pour partager du code commun entre elles. Vous pourriez tout aussi bien résoudre le même problème en ayant un niveau intermédiaire et des solutions hétérogènes accédant à votre niveau intermédiaire au lieu de votre base de données, et ce niveau intermédiaire partage ce code.

— Ekevoo

1

fyi cette réponse est baloney, 6 ans plus tard - seules les données vont dans la base de données. Vous mettez de la logique là-dedans, vous avez beaucoup de problèmes sur toute la ligne. Créez simplement un microservice dans la langue de votre choix qui accède à la base de données.

— NimChimpsky

6

Notre équipe a une règle douce ici. Parfois, il est préférable de résoudre la logique métier en T-SQL, parfois il est plus facile de le faire en c # (couche métier).

Nous avons donc une solution pragmatique: mettre là où cela convient le mieux. Je sais que la théorie est parfois très stricte à ce sujet ... mais c'est la théorie :-)

— gsharp
source

2

C'est sûrement la pire solution de toutes? Comment un développeur de maintenance sait-il où la logique est stockée? J'imagine que parfois, il se glisse également dans la couche application, ou pire encore, l'interface utilisateur?

— Paul T Davies

2

Nan. C'est toujours dans Business Layer ou T-SQL. Déterminer où la logique est stockée est probablement le plus petit problème en matière de maintenance.

— gsharp

Que se passe-t-il lorsque quelqu'un rejoint l'équipe et que vous lui dites cette règle? Comment sont-ils censés savoir où quelque chose "va mieux"? Cela me semble presque une non-règle. Très subjectif en fonction de l'individu.

— RationalGeek

3

Allez les gars, sérieux? Nous employons des gens qui ont un cerveau pour penser et qui ont une certaine expérience à bord. Alors .. oh oui ils ont une bouche pour demander et faire la conversation. Je peux dire que notre logiciel nécessite très peu de maintenance et que de nouvelles fonctionnalités peuvent être mises en œuvre correctement par presque tout le monde dans notre équipe. ne peut pas se tromper ce que nous faisons.

— gsharp

4

Je ne vois vraiment aucun sens à mal utiliser c # pour des choses que SQLServer peut faire tellement mieux, et vice-versa.

— gsharp

3

Il y a des avantages et des inconvénients pour les deux (à mon avis):

Les procédures stockées peuvent devenir un cauchemar si vous n'utilisez pas une sorte de contrôle de source SQL (ce que beaucoup d'endroits n'utilisent pas) et que plusieurs développeurs y travaillent. Quelqu'un peut modifier une procédure stockée et oublier de mettre à jour le code qui appelle cette procédure et avant de le savoir, vous venez de créer et de déployer un site qui va lever des exceptions non gérées (incompatibilité du nombre de paramètres, etc.).

D'un autre côté, les procédures stockées permettent des corrections de bogues plus rapides dans certaines situations. S'il y a un bogue avec une procédure stockée, il suffit de le corriger et vous avez terminé. Une correction de bogue dans un ORM nécessite une reconstruction. Selon votre processus de construction, cela peut être long / ennuyeux.

— AndrewC
source

+1 pour le besoin de contrôle de source avec les proc stockés si vous comptez les utiliser fortement. De nombreux administrateurs de base de données avec lesquels j'ai travaillé sont très résistants à cette idée.

— RationalGeek

2

Nous mettons toujours notre logique métier dans la couche logique métier. Si vous le mettez dans la procédure stockée, il sera perdu une fois que vous aurez changé votre SGBDR.

— šljaker
source

16

La dernière chose qui change est le SGBDR ;-)

— gsharp

Cela signifie-t-il que vous limitez la procédure stockée à la récupération, la mise à jour et l'insertion des données ...?

— Pravin Patil

1

Chaque grand système que j'ai vu, la réalité est que la base de données EST le système. Les langages de programmation deviennent presque hors de propos à ce stade comme juste le "front end" ..

— Darknight

2

@gsharp, ce n'est pas toujours vrai. Vous pouvez soit ajouter un autre SGBDR comme Oracle, soit remplacer complètement celui existant. Ou, dans certains cas, vous souhaitez remplacer les données réelles par des données factices.

— šljaker

2

@ šljaker bien sûr, ce n'est pas toujours vrai. Mais il est plus probable que le programme change (refonte du logiciel, nouveaux langages de programmation, etc.) plutôt que la base de données.

— gsharp

2

La «logique métier» est un peu vague. Je veux dire qu'il n'a pas de définition unique. Une règle d'or consiste à minimiser la communication entre les niveaux lorsque vous le pouvez. Ainsi, vous n'avez pas besoin d'envoyer un nom de client vide au serveur pour le vérifier avant d'insérer une ligne.

Il existe des cas, lorsqu'une règle est basée sur une lecture de base de données. Supposons que vous souhaitiez transférer de l'argent du compte 1 vers le compte 2. Vous devez lire les deux comptes, vous assurer qu'ils sont en bon état et que le montant du compte 1 est suffisant. Dans ce cas, le serveur est un meilleur candidat pour cette règle car le client (qui est le BL ici) n'a pas besoin d'émettre 3 appels au niveau base de données pour ce processus.

Bien sûr, si vous avez besoin que votre solution soit indépendante de la base de données, faites des procs stockés uniquement pour CRUD (le cas échéant).

— Aucune chance
source

1

La logique doit toujours être dans le BLL car:

Il peut être testé correctement
Lorsque SQL 20XX devient obsolète et que vous devez passer à la dernière version, vous n'avez pas à réécrire votre code.
Les gens ne sont pas tentés de faire des changements à la volée (ce qui semble être avancé comme argument pour les SP)
D'après mon expérience, les SP sont le principal point d'erreur du développeur, en particulier après quelques générations de maintenance / modifications.

Je pense qu'il devrait y avoir une loi qui stipule qu'après qu'un SP fait plus de X lignes, il ne fonctionne pas comme prévu.

— Paul T Davies
source

Quel est le problème avec les changements à la volée? S'il y a un bogue dans une procédure stockée et qu'il est facilement corrigé, corrigez-le. C'est positif car cela signifie que vous n'avez pas besoin de faire une nouvelle version pour quelque chose de trivial. Tant que les gens ne commencent pas à masquer les bogues dans le code en modifiant les procédures stockées, je ne vois aucun problème.

— AndrewC

Par changements à la volée, je veux dire des choses qui ne sont pas testées et qui ne suivent pas une procédure de sortie officielle. Et oui, les changements de sp pour masquer les bogues de code sont quelque chose que j'ai vu un peu.

— Paul T Davies

0

Nous créons une couche de services qui contient toute notre logique métier implémentée dans la langue choisie et utilisons uniquement la base de données pour les requêtes. Cette approche est en quelque sorte mandatée par nous car notre objectif est de créer des solutions COTS pour fournir des applications avec diverses implémentations de bases de données. Hibernate s'est avéré être une bouée de sauvetage pour nous dans ces circonstances.

Je pense que le plus grand avantage de cette approche, outre la portabilité de la base de données, est que vous pouvez trouver toutes vos réponses en une seule recherche.

De plus, malgré certaines des réponses à un forum, j'ai un ami travaillant pour une compagnie d'assurance Fortune 100 qui a effectué 2 conversions de base de données en trois ans parce que la base de données de choix pour la société a changé.

— Thom
source

0

Dans mon expérience limitée, je préfère maintenir l'intégrité des données avec des procédures stockées et d'autres fonctionnalités de base de données. Par exemple, si j'implémentais un transfert de fonds entre deux comptes, j'écrirais une procédure stockée. Je trouve utile de pouvoir utiliser plusieurs langages d'application.

— Kevin Cline
source