Contrôleur de Base du constructeur d'injection dans ASP.NET MVC avec l'Unité

J'ai un contrôleur de base dans mon MVC 5 projet qui met en œuvre conjointement à la fonctionnalité. Cette fonctionnalité nécessite quelques dépendances. Je suis à l'aide de l'Unité 3 à injecter ces implémentations dans mes contrôleurs, un modèle qui a bien fonctionné jusqu'à ce que j'ai changé mon contrôleurs d'hériter de ce contrôleur de base. Maintenant, je suis en cours d'exécution dans le problème suivant:

public class BaseController : Controller
{
    private readonly IService _service;

    public BaseController(IService service)
    {
        _service = service;
    }
}

public class ChildController : BaseController
{
    private readonly IDifferentService _differentService;

    public ChildController(IDifferentService differentService)
    {
        _differentService = differentService;
    }
}

C'est compréhensible de lancer une erreur de 'BaseController' does not contain a constructor that takes 0 arguments. L'unité n'est pas la résolution de la construction de la BaseController, donc il ne peut pas injecter les dépendances en elle. Je vois deux façons évidentes de la résolution de cette question:

1.) Appeler explicitement la BaseController ctor et ont chacun ChildController ctor injecter le BaseController dépendances

public class ChildController : BaseController
{
    private readonly IDifferentService _differentService;

    public ChildController(IDifferentService differentService,
                           IService baseService)
        : base(baseService)
    {
        _differentService = differentService;
    }
}

Je n'aime pas cette approche pour plusieurs raisons: premièrement, parce que le ChildControllers n'êtes pas faire usage de dépendances supplémentaires (de sorte qu'il provoque constructeur de la météorisation chez l'enfant, des contrôleurs pour aucune raison), et, plus important encore, si jamais j'ai changer la signature du constructeur du Contrôleur de Base, j'ai du modifier le constructeur de signatures de chaque enfant contrôleur.

2.) Mettre en œuvre les BaseController les dépendances via la propriété d'injection

public class BaseController : Controller
{
    [Dependency]
    public IService Service { get; set; }

    public BaseController() { }
}

J'aime cette approche mieux - je ne suis pas à l'aide de l'une des dépendances de la BaseController du code de constructeur - mais il fait de l'injection de dépendance de la stratégie du code incompatibles, ce qui n'est pas l'idéal non plus.

Il y a probablement une bien meilleure approche qui implique une sorte de BaseController dépendance de la fonction de résolution qui appelle à l'Unité de conteneur pour le tri ctor de la signature de la méthode, mais avant de me lancer dans l'écriture de quelque chose de trop impliqué, je me demandais si quelqu'un avait résolu ce problème avant? J'ai trouvé quelques solutions qui circulent sur le web, mais ils ont des solutions de contournement comme Localisateur de Service que je ne veux pas utiliser.

Merci!

InformationsquelleAutor NWard | 2014-02-20
  1. 29

    La première chose que vous devez comprendre, c'est que vous n'êtes pas à l'instanciation de la base de contrôleur. Vous êtes l'instanciation de l'enfant contrôleur, qui hérite de la base de contrôleurs d'interface et de fonctionnalités. C'est une distinction importante. Quand vous dites "la ChildControllers n'êtes pas faire usage de dépendances supplémentaires", alors vous êtes tout à fait tort. Parce que le ChildController EST la BaseController ainsi. Il n'y a pas deux classes différentes créé. Juste une classe qui implémente les fonctionnalités.

    Donc, depuis ChildController EST UN BaseController, il n'y a rien de mal ou d'étrange à propos d'un passage de paramètres dans l'enfant contrôleurs constructeur qui appelle les classes de base du constructeur. C'est la façon dont il devrait être fait.

    Si vous modifiez votre classe de base, vous devrez probablement changer votre enfant des classes de toute façon. Il n'y a aucun moyen d'utilisation du constructeur d'injection pour injecter de la classe de base des dépendances qui ne sont pas inclus dans la classe enfant.

    Je ne recommande pas la propriété de l'injection, car cela signifie que vos objets peuvent être créés sans l'initialisation correcte, et vous devez vous rappeler de les configurer correctement.

    BTW, les termes sont sous-classe de super-classe. Un "enfant" est une sous-classe, le parent est le "super-classe".

    • Vous avez raison! J'ai ajouté un contrôleur de base comme une solution au besoin partagé de la fonctionnalité sans tenir pleinement compte de la OO implications. Je pense que ce que je vais faire est de refactoriser un peu pour s'assurer que les dépendances de base sont belle et bien rangé, et passer à travers l'enfant constructeurs comme vous le suggérez. Merci Eric!
    • C'est peut-être le droit de réponse ici, mais c'est malheureusement que, même si je peux joindre l'initialisation de code au sein de la classe de base, chaque classe dérivée de a à mettre en œuvre le bon constructeur. J'ai souvenir de type dans le même constructeur pour chaque classe dérivée. Et de toute modification des données, je suis de passage pour le constructeur exige de changer chaque classe qui en dérive. Il serait de loin préférable d'être en mesure de maintenir ce uniquement à partir de la classe de base.
    • Cet argument n'est pas particulièrement convaincante, car les constructeurs sont là pour une raison... Vous voulez initialiser l'objet avec des données spécifiques. Si vous "oubliez" de manière à inclure le droit constructeur, la tâche que vous souhaitez accomplir ne fonctionne pas car il n'y aura pas un constructeur que vous avez besoin et vous allez rapidement vous remarquez que votre erreur. C'est comme se plaindre que vous avez à se "souvenir" pour ajouter des propriétés que vous avez besoin pour une classe... vous n'irez pas très loin si vous ne vous souvenez pas.
    • Je ne pense pas que je plaide pour une chose ou une autre. J'étais en soulignant ce que je vois que certaines limitations de cette approche. Un des gros points de la programmation orientée objet de la programmation de l'encapsulation. Et je maintiens que certains de ce qui a été perdu avec cette approche, et j'ai tenté de décrire certaines des questions qui suivent en conséquence.
    • ce que vous appelez une "approche" est la façon dont tous les langages orientés objet que je suis consciente du travail, et puisque c'est.. par définition, "l'approche orientée-objet", je ne comprends pas très bien ce que tu veux dire. À ma connaissance, tous les langages orientés objet que de mettre en œuvre l'héritage de la mise en œuvre de la manière dont la classe dérivée est la seule instance de l'objet, et donc il y a pas d'autres instances que quelque chose comme l'Unité ou tout autre conteneur d'injection de dépendances peut injecter une valeur si la classe dérivée elle-même de ne pas mettre en œuvre que constructeur.
    • Je pense que ce que vous semblez le suggérer, c'est que la base de constructeurs de classe doivent être exposés par défaut, ce qui est vraiment une chose très différente de ce que l'affiche originale a été demandé. Si c'est ce que vous voulez dire, alors je vous suggère de lire l'un des nombreux articles sur le sujet de pourquoi les constructeurs ne sont pas héréditaire en C++, Java et d'autres langues (notamment en C#). FWIW, C++-11 a ajouté une fonctionnalité qui permet au compilateur de créer automatiquement correspondance des constructeurs dans les classes de base, mais ce n'est pas tout à fait la même chose.
    • Sens +1..

    InformationsquelleAutor Erik Funkenbusch
  2. 12

    Avec ASP.Net 5 et il est intégré dans DI

    public class BaseController : Controller
{
    protected ISomeType SomeMember { get; set; }

    public BaseController(IServiceProvider serviceProvider)
    {
        //Init all properties you need
        SomeMember = (SomeMember)serviceProvider.GetService(typeof(ISomeMember));
    }
}

public class MyController : BaseController  
{
public MyController(/*Any other injections goes here*/, 
                      IServiceProvider serviceProvider) : 
 base(serviceProvider)
{}
}

    Mise à JOUR

    Il y a aussi une méthode d'extension de Microsoft.Extensions.DependencyInjection pour la rendre plus

    SomeMember = serviceProvider.GetRequiredService<ISomeMember>();
    • C'est un grand plus. Est-il possible de mettre en œuvre un contrôleur de base sans DI ASP.NET 4.5?
    • Pas sûr de ce que tu veux dire. Vous pouvez utiliser de l'Usine+Singleton au lieu de DI dans BaseController.
    • oui, le mépris. J'ai laissé de l'espace de Noms des Contrôleurs. Ce projet, je suis en train de travailler sur n'a pas DI implimented.
    • Bon, va bien avec MVC 6
    • pourriez-vous fournir un exemple supplémentaire? J'ai été confronté à contrôleur doit avoir sans paramètre public ctor d'erreur.
    • soit vous utilisez une version différente de la MVC MVC (4\5, WebAPI, etc), ou d'utiliser celui par défaut conteneur d'injection de dépendances. L'exemple est pour ASP.Net Core, MVC 6, qui a été appelé ASP.Net 5 pour le moment, j'ai ajouté ma réponse. Dans ASP.Net de Base vous avez rarement le constructeur sans paramètre et il n'y a pas de restriction de ce type n'existe
    • MVC 5 est utilisé et MME DI. J'ai résolu mon problème en ajoutant public HomeController() : this(DependencyInjectionResolver.ServiceProvider) { } etc
    • au lieu de cela, vous pouvez simplement utiliser DependencyInjectionResolver.ServiceProvider tout le chemin ou la création d'une propriété dans le contrôleur de base qui renvoie directement. Il n'y a pas beaucoup de sens en passant propriété statique dans le constructeur de classe de base

    InformationsquelleAutor Vitaly
  3. 0

    J'ai pris un peu différente (mais pour moi, assez évident, et probablement commun) approche. Il fonctionne pour moi, mais il peut y avoir des pièges, je ne suis pas au courant.

    J'ai créé le service commun de propriétés dans mon BaseController classe que la plupart de mes contrôleurs utilisent. Ils obtiennent instanciée lorsqu'ils sont nécessaires/référencées.

    Si il y a un service à un contrôleur particulier des besoins qui est de moins en moins utilisé, je l'injecter dans le constructeur du contrôleur comme d'habitude.

    using JIS.Context;
using JIS.Managers;
using JIS.Models;
using JIS.Services;
using System;
using System.Collections.Generic;
using System.Web;
using System.Web.Mvc;
namespace JIS.Controllers
{
public class BaseController : Controller
{
public BaseController()
{
ViewBag.User = UserManager?.User;
}
private IUserManager userManager;
public IUserManager UserManager
{
get
{
if (userManager == null)
{
userManager = DependencyResolver.Current.GetService<IUserManager>();
}
return userManager;
}
set
{
userManager = value;
}
}
private ILoggingService loggingService;
public ILoggingService LoggingService
{
get
{
if (loggingService == null)
{
loggingService = DependencyResolver.Current.GetService<ILoggingService>();
}
return loggingService;
}
set { loggingService = value; }
}
private IUserDirectory userDirectory;
public IUserDirectory UserDirectory
{
get
{
if (userDirectory == null)
{
userDirectory = DependencyResolver.Current.GetService<IUserDirectory>();
}
return userDirectory;
}
set { userDirectory = value; }
}
private ApplicationDbContext appDb;
public ApplicationDbContext AppDb
{
get
{
if (appDb == null)
{
appDb = new ApplicationDbContext();
}
return appDb;
}
set
{
appDb = value;
}
}
protected override void Dispose(bool disposing)
{
if (disposing && appDb != null)
{
appDb.Dispose();
}
base.Dispose(disposing);
}
}
}

    Dans mon contrôleur, j'ai simplement sous-classe de cette BaseController:

    public class UsersController : BaseController
{
//and any other services I need are here:
private readonly IAnotherService svc;
public UsersController(IAnotherService svc)
{
this.svc = svc;
}
...
}

    De cette façon, les services communs sont générées à la volée quand ils sont nécessaires, et sont à la disposition de mes contrôleurs, sans beaucoup de passe-partout.

    InformationsquelleAutor DBatesX