Meilleures pratiques d'Entity Framework : Quelle couche doit appeler SaveChanges() ?

Question

Pour un modèle de données propre, j'ai des doutes sur ce point...

En utilisant un flux de travail d'approbation comme exemple, disons que dans mon application web, j'ai une page qui permet à un utilisateur de marquer une demande d'approbation. MyEntityObject pour approbation. MyEntityObject a quelques propriétés qui contrôlent son flux d'approbation, donc j'ai une méthode utilitaire commune appelée FlagForApproval(MyEntityObject eo) .

Est-ce que le page appelez FlagForApproval() pour définir uniquement les propriétés nécessaires et ensuite appeler SaveChanges() quand il est prêt, ou devrait FlagForApproval() enregistrer les changements ?

Le fait que la méthode utilitaire enregistre les modifications semble faire un peu plus que ce qui lui est demandé (et si ce n'était qu'une étape dans une série d'opérations ?), mais en même temps, faire en sorte que la page appelle SaveChanges() et engage les données dans la base de données semble être considéré comme trop proche des responsabilités de la couche de données.

Qu'en pensez-vous ?

(Mise à jour : FWIW, jusqu'à présent, j'ai fait en sorte que les méthodes utilitaires appellent SaveChanges(), de cette façon la page n'a qu'un seul ensemble d'exceptions à gérer, que ce soit la validation ou les données).

Answer 1

Mon opinion actuelle sur cette question est que la couche logique de l'entreprise doit toujours appeler les modifications de sauvegarde après avoir validé les données. Lorsque l'utilisateur clique sur le bouton "Sauvegarder", je transmets les entités qui doivent être validées à la BLL, et c'est elle qui décide d'appeler SaveChanges().

Je suis aussi curieux que vous de voir ce que les autres disent, car ce problème (et bien d'autres) me tourmente depuis que j'ai commencé à utiliser EF.

Answer 2

La clé est de séparer le langage des bases de données et celui des services. Si la méthode de l'utilitaire doit sauvegarder les modifications, alors elle le fait, sinon, indiquez clairement qu'elle ne le fait pas et que des étapes supplémentaires sont nécessaires. L'utilitaire ne devrait pas avoir une méthode appelée SaveChanges, il devrait avoir des méthodes liées au processus, comme StartProcess ou LoadToBatch.

Considérer le service public comme un service et ne pas penser à la base de données. Le "FlagForApproval" ressemble à une opération de base de données, essayez de penser à la méthode comme quelque chose comme "StartApprovalProcess" ou quelque chose d'autre lié au processus. StartApprovalProcess effectuerait tout le travail et les commits.

S'il y a plusieurs étapes, faites en sorte que chaque étape indique indirectement qu'il peut y avoir d'autres étapes. Seule la dernière étape commet. Bien que la dernière étape ne fasse que sauvegarder les changements, il faut la lire comme un processus tel que move ou start.

Ex :

1. LoadToBatchApproval(MonEntityObject eo)

2. ValidateApprovalBatch()...

3. MoveBatchToProcessing()...

Answer 3

Je ne suis pas sûr qu'il y ait une bonne ou une mauvaise réponse, mais il semble plus propre (imo) de laisser FlagForApproval gérer le processus de démarrage du flux de travail. Cela inclut le fait d'indiquer à la couche de données de faire persister l'état de l'objet (c'est-à-dire de sauvegarder les modifications). Cependant, cela suppose que vous avez des exigences commerciales indiquant qu'une fois qu'un flux de travail est lancé, l'état doit être persisté de sorte que si quelque chose se produit (par exemple, un crash du serveur), le processus de flux de travail continue à partir de la dernière étape.