J'ai lu que DBContext L'objet doit être créé comme instancePerhttprequest, pas unique, en raison de sa nature thread-dangerose et qu'elle peut consommer trop de ressources entre les demandes de la SENCE. Mais j'utilise des objets de référentiel qui utilise l'instance DBContext. Devrais-je faire des instancesPartPeQuRequest ou les rendre sophistiqués et utiliser dépendencyResolver pour obtenir le dbcontext actuel.
Quelle serait la meilleure conception de la création d'objets, pour Autofac (ou tout autre DI), DBContext, le référentiel et la demande Web basée sur des services?
Une autre question, combien il est coûteux de créer un objet DBContext différent pour chaque référentiel ou service pour chaque demande Web (comme 10-15 d'entre eux dans une demande)?
3 Réponses :
dbcontext est incroyablement bon marché pour instancier pour que je ne m'inquiéterais pas trop à peu près au temps nécessaire pour en obtenir un nouveau.
Le problème que j'ai avec Scoping autour de DBContext n'est pas tant de sécurité de thread saine isolement. Parce que tout le monde peut appeler Enregistrer les modifications et valider le graphique de l'objet entier à la base de données, vous souhaitez vous assurer que vous ne l'appelez que sur un contexte avec vos modifications spécifiques.
Une autre chose clé à comprendre à propos de DBContext est que la performance dégrade plus les éléments de suivi. Cela signifie que si vous le liez dans Singleton, vous pouvez causer des problèmes de performance assez graves. (Il y a des moyens autour de cela, mais c'est vraiment bon d'être au courant de voir mon message sur ce Ma préférence personnelle pour les applications Web consiste à lier à la fois votre contexte et votre référentiel dans la portée d'un HTTPRequest. Cela signifie que seule votre thread de demande actuelle sera en mesure d'enregistrer des modifications, et il limite également la quantité d'éléments que vous êtes susceptible de suivre.
Désolé, un peu de ma terminologie ne correspond probablement pas à Autofac car je suis moi-même un homme Ninject moi-même :)
"Tout le monde peut appeler des modifications et valider le graphique de l'objet entier". C'est une question de sécurité de la sécurité, n'est-ce pas? Vous serez simplement en merde sérieuse lorsque vous partagez un dBContext threads / demandes d'accross.
@Steven Ouais Cela s'applique absolument à la filetage, mais je suggérerais que c'est encore plus étendu qu'un problème de filetage. Le risque est que même dans une seule application filetée si vous devez interroger des données et une boue avec elle (sans intention de persister ces changements) et de réutiliser ultérieurement le contexte pour effectuer une mise à jour de la mise à jour et des modifications précédentes des objets ci-joints. être engagé. C'est l'une des raisons pour lesquelles il est recommandé de garder la portée de DBContext aussi petite que possible (c'est-à-dire juste votre unité de travail).
@Steven En outre, les problèmes de performance avec une utilisation à long terme de DBContext le rendent assez pratique (sans gérer la main sur le graphique de suivi)
dbcontext est bon marché pour instancier, alors je le conçois de manière à ce que chaque service ait sa propre instance. 10-15 par demande est correcte, sauf si vous rencontrez un problème, vous pouvez retrouver le nombre de DBContexts instanciés. Tout le reste sent l'optimisation pré-mature pour moi.
J'ai essayé de rester diagnostique, car j'utilise principalement StructureMap.
dbcontext est votre unité de travail et ne convient donc jamais à une portée spécifique. Traitez-le comme tel. Parfois, une demande carte directement à une UOW, mais pas nécessairement toujours. Considérez ceci avant de la mettre en place à la demande.
Dupliqué possible de Un dBContext par demande Web ... Pourquoi?
Connexes: Stackoverflow.com/Questtions/5324147/...