MS SQL Server
  1. MS SQL Server
  3. Business Logic dans une procédure stockée ou une application
Intereting Posts
restaurer la database attach attach sql Couper l'espace de fin du contenu de la table Requête SQL Server impliquant des sous-requêtes – problèmes de performances Comment sélectionner des lignes avec horodatage près des lignes adjacentes? comment insert des données s'il contient une apostrophe? Est-ce que SQLXML brise 1NF? Validation d'une input List dans SQL Comment définir un paramètre de type table null lors de l'appel d'une procédure stockée avec JTDS Obtenir l'année et le mois à partir de SQL Comment puis-je faire cette requête par SQL pur? EF6 avec la connection sous-jacente localdb v13 n'a pas pu s'ouvrir SqlCommand, en passant quelque chose qui pourrait être nul Donner le nom d'alias avec l'espace en sql Est une bonne pratique pour désactiver les index avant l'insertion de nombreux loggings sur SQL Server? comment get la valeur de la colonne de colonne xml dans la table

Business Logic dans une procédure stockée ou une application

J'ai un bon de command dans mon système. Un user peut modifier le bon de command et l'save dans la database. Dans le formulaire, il y a un champ de checkbox appelé " Suivre l'ordre " qui, s'il est coché, ajoute l'identifiant de la command à la table TrackedOrders .

Maintenant, ma question est, quelle est la meilleure solution:

  1. Pour utiliser une seule procédure stockée ( SaveOrder ) qui met d'abord à jour tous les champs Order à l'aide d'une instruction UPDATE et appelle un autre SP ( AddTrackedOrders ) en interne si la checkbox "isTrackedOrder" value = true.

  2. Ou pour appeler le SaveOrder sp qui ne mettra à jour que la command, puis vérifiera le code de l'application if isTrackedOrder=true -> call AddTrackedOrders .

Les deux appels doivent être dans la même transaction! Signifie que si SaveOrder réussit et que AddTrackedOrders échoue, alors SaveOrder devra également être annulé.

Je sais qu'il est possible de créer des transactions dans le code mais je ne suis pas sûr quelles sont les implications d'une telle méthodologie.

Modifier:

Après une courte search, j'ai remarqué que la plupart des gens préfèrent utiliser TransactionScope. Je ne suis toujours pas certain de savoir comment cela est meilleur car cela rend le time de transaction beaucoup plus long (et donc plus enclin aux erreurs) et fait plusieurs tours de la database. De plus, vous devrez probablement append plus de procédures stockées si leurs résultats contrôlent le stream du scénario métier …

Merci a tous!

Personnellement, je préfère exécuter la logique métier dans le code , pas dans la base de données pour différentes raisons (C # vs SQL, versionnage du code, réutilisation … etc.).

Vous pouvez envelopper les appels de code et de procédure stockée dans un TransactionScope pour exécuter les deux atomiquement: 

 using(TransactionScope scope = new TransactionScope()) { // Executes some business logic against the DB using a DB context ... // Executes some stored procedure here ... // commits transaction scope.Complete(); }

Vous avez quelques choix: procédures stockées, transactions dans le code et model d'unité de travail.

Je suggère fortement de mettre en œuvre le model d'unité de travail pour gérer les transactions dans le code, plutôt que de gérer les transactions dans des situations ponctuelles ou de mettre en œuvre des procédures stockées.

Les procédures stockées étaient la voie à suivre, principalement en raison de la performance. Mais avec des améliorations de l'optimization des performances avec des requêtes dynamics dans les implémentations récentes de SQL Server, cela devient less préoccupant (même si dans certains cas, il peut encore y avoir un petit avantage). Et avec la performance n'est plus un avantage, avoir la logique centralisée dans le code w / votre autre logique métier a de plus en plus de sens.

Le model d'unité de travail vous permettra de gérer vos transactions via le code beaucoup plus facilement, et il prendra en charge plusieurs couches de transactions (transaction au sein d'une transaction).

L'unité de travail est beaucoup plus facile à implémenter avec Entity Framework (ou n'importe quel ORM), mais si vous êtes attaché à ADO.NET et n'utilisez pas un ORM, il existe des moyens de le faire. Cet article donne un assez bon aperçu de l'implémentation de UoW w / ADO.NET.