Ninject : gestion de la durée de vie des objets et de l'injection de dépendances
Question 1 : nettoyage de DbContext
Quand en utilisant Ninject, vous n'avez pas à vous soucier de la suppression manuelle des instances DbContext. Ninject supprime automatiquement tout objet jetable qui n'est pas lié à InTransientScope(). Puisque vous utilisez très probablement InParentScope() ou d'autres étendues, Ninject gérera la suppression lorsque la portée correspondante sera collectée par le ramasse-miettes.
Question 2 : éviter l'injection de DbContext dans le contrôleur de base
Il est généralement recommandé d'éviter d'utiliser des classes de base pour les contrôleurs MVC. Ils ont tendance à violer le principe de responsabilité unique et à conduire à des objets divins. Envisagez plutôt d'utiliser des filtres enregistrés globalement pour gérer les problèmes transversaux.
Exemple :
Supposons que vous souhaitiez définir des propriétés ViewBag communes en fonction de l'utilisateur actuel. Vous pouvez créer un IAuthorizationFilter comme ceci :
public class CurrentUserProfileFilter : IAuthorizationFilter { private readonly MyDbContext context; public CurrentUserProfileFilter(MyDbContext context) { this.context = context; } public void OnAuthorization(AuthorizationContext filterContext) { // Set ViewBag properties based on current user information from DbContext } }
Ensuite, enregistrez le filtre globalement dans votre FilterConfig :
public class FilterConfig { public static void RegisterGlobalFilters(GlobalFilterCollection filters) { FilterProviders.Providers.Insert(0, new GlobalFilterProvider(DependencyResolver.Current)); } }
Cela définira automatiquement les propriétés ViewBag à chaque requête sans vous obliger à le faire. injectez MyDbContext dans vos contrôleurs.
Question 3 : Contexte de base de données paresseux Instanciation
Par défaut, Ninject crée des objets avec empressement, mais il est possible de rendre un objet lié par Ninject paresseux (créé uniquement à la première demande).
Cependant, cela n'est pas recommandé pour DbContext puisqu'il a une surcharge d'initialisation importante, il serait donc inutile de différer sa création. De plus, un DbContext doit être supprimé une fois terminé et sa durée de vie doit être contrôlée en conséquence.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!