Trop d'injection de dépendances

Je recommanderais d'utiliser la convention sur le principe de configuration, avec le localisateur de service.

Déclarez quelque chose comme l'interface IApplicationHandler dans votre programme, par exemple

    [TestClass]
    public class AccountingApplicationQueryHandlerTests 
    {
        [TestMethod]
        public void TestPopulate()
        {
            // arrange
            var application = new Application();
            var handler = new AccountingApplicationQueryHandler(); // inject mocks here

            // act
            var result = handler.Populate(application);

            // Assert
            Assert.AreEqual(result. PaymentDetail, "whatever");
        }
    }

Ensuite, écrivez des morceaux de votre code, avec des dépendances et autres, par exemple

var queryHandlers = Assembly.GetAssembly(typeof(IApplicationQueryHandler)).GetExportedTypes()
            .Where(x => x.GetInterfaces().Any(y => y == typeof(IApplicationQueryHandler)));

foreach(queryHandler in queryHandlers) {
  services.AddTransient(typeof(IApplicationQueryHandler), queryHandler);
}
// repeat the same for IApplicationSaveHandler

Ensuite, dans votre contrôleur, faites quelque chose comme

public class ApplicationController: Controller
{
   public readonly IServiceProvider _serviceProvider;
   
   public ApplicationController(IServiceProvider sp) {
     _serviceProvider = sp;
   }

  public Application Load(string applicationTypeId, string applicationId)
  {
     var application = new Application(); // or get from db or whatever
     var queryHandlers = _serviceProvider.GetServices(typeof(IApplicationQueryHandler));

     foreach(var handler in queryHandlers) {
       application = handler.Populate(application);
     }
     
     return application;
  }

  [HttpPost]
  public bool Save(Application application) 
  {
    var result = true;
    var saveHandlers = _serviceProvider.GetServices(typeof(IApplicationSaveHandler));

     foreach(var handler in queryHandlers) {
       result = handler. Save(application);
     }
     
    return result;
  }
}

Vous devrez enregistrer vos gestionnaires, ce que vous pouvez faire par exemple comme ceci:

public class AccountingApplicationQueryHandler : IApplicationQueryHandler
{
   public Application Populate(Application application) {
     //// Load the payment details, if no payment made calculate the payment
    return application;
   }
}

public class AccountingApplicationSaveHandler : IApplicationSaveHandler
{
   public Bool Save(Application application) {
     //// Save the payment details for the application
    return true; // this just flags for validation
   }
}

// repeat for all other properties

Maintenant, enfin, vous pouvez écrire des tests unitaires pour une partie du code comme ceci

public interface IApplicationQueryHandler 
{
   Application Populate(Application application);
}

public interface IApplicationSaveHandler 
{
   Bool Save(Application application);
}

Et vous pouvez tester que votre contrôleur appelle les bonnes choses en se moquant de IServiceProvider et en l'injectant avec quelques gestionnaires factices pour confirmer qu'ils sont appelés correctement.

"J'ai actuellement une classe avec environ 40 injections de dépendances ..." - Oh mon Dieu!

"C'est un test unitaire difficile à maintenir ..." - Je n'en doute pas du tout!

REFACTORISATION SUGGÉRÉE:

1. Créez une classe qui gère les "Applications" (par exemple "ApplicationManager").

2. Créez une classe abstraite "Application".

   Un avantage de la "classe abstraite" par rapport à "l'interface" ici est que vous pouvez mettre du "code commun" dans la classe de base abstraite.

3. Créez une sous-classe concrète pour chaque "Application": public class NewLicense : Application , public class LicenseRenewal : Application , etc. etc.

... ET ...

4. Utilisez DI principalement pour les "services" dont chaque classe concrète a besoin.

   Je parie que les constructeurs de vos classes concrètes individuelles n'auront besoin que d'injecter trois ou quatre services ... au lieu de 40. Qui sait - peut-être que votre classe de base n'aura pas du tout besoin de DI.

C'est en fait une conception que nous utilisons dans l'un de nos systèmes de production. C'est simple; c'est robuste; c'est flexible. Cela fonctionne bien pour nous :)

Suite à la réponse de zaitsman, vous pouvez également créer AggregatedApplicationQueryHandler et AggregatedApplicationSaveHandler et transmettre une collection d'implémentation concrète de IApplicationQueryHandler et IApplicationSaveHandler à son constructeur.

Ensuite, vous n'avez pas besoin de foreach boucle à l'intérieur du contrôleur (vous bouclez sur les gestionnaires à l'intérieur du gestionnaire agrégé) et n'avez toujours qu'un seul gestionnaire passé au contrôleur. Passer son paramètre par constructeur ne devrait pas être si pénible.

Vous pouvez également créer une façade sur certains petits services et regrouper leurs fonctions en un seul service de façade plus grand.