Injection de dépendances en .NET, pattern, intérêt et outils

Cet article va s'attarder sur les diverses techniques d'injection de dépendances

Au début de la rédaction de cet article, bien qu'ayant déjà une idée assez claire des différents framework, ainsi que des différents principes mis en œuvre, je me suis rendu compte (à mes dépens) qu'une incertitude restait sur les différents termes gravitant autour de cette technique.

Pour clarifier, on distinguera les termes suivants :

1. Inversion de contrôle : l'inversion de contrôle (IoC) est un concept de haut niveau en développement orienté objet. L'inversion de contrôle veut que lorsqu'un module effectue un traitement, le contrôle du traitement soit déporté vers l'appelé, et non pas vers l'appelant. En pratique, on va chercher à diminuer au maximum la connaissance qu'à l'appelant de la mécanique interne de l'appelé ;
2. Inversion de dépendances : l'inversion de dépendances (DI) est un principe de développement orienté objet. L'inversion des dépendances est une des implémentations possibles de l'inversion de contrôle. J'ai déjà mentionné ce principe précédemment, mais pour éviter un (second !) lien vers le premier article, la définition simplifiée de ce principe est que, pour diminuer le couplage entre les classes, on va ajouter une interface entre chaque classe, de façon à ce qu'au lieu d'appeler une classe physique, l'appelant appelle une interface, ceci permettant d'ajouter un niveau d'abstraction supplémentaire entre l'appelant et l'appelé ;
3. Injection de dépendances : l'injection de dépendances est une technique permettant de mettre en œuvre l'inversion de dépendances.

On trouve régulièrement l'un des trois termes ci-dessus utilisés pour qualifier l'injection de dépendances.

En programmation orientée objet, de façon classique, un objet (classe ou module) va contenir un ensemble de dépendances sur d'autres objets, auxquels il va déporter tout ou partie de ses traitements. Le bon côté de la chose est que l'on évite que nos objets contiennent trop de comportements (les rendant difficiles à maintenir). Le mauvais côté est que chacun de ces objets référencés devient une dépendance forte, car notre objet appelant doit connaitre chacun des objets qu'il va utiliser avant de les instancier.

Par exemple, prenons le cas d'une classe d'accès aux données. L'exemple standard d'appel à une fonction située dans une classe d'accès aux données aura la forme suivante :

public class CustomerService {
    public Customer GetOneCustomer(int customerId){
       CustomerRepository _repository = new CustomerRepository();
       return new Customer(_repository.GetOneById(customerId));
    }
}

Ce code, au demeurant simple à comprendre, pose, dans le cadre de l'inversion de contrôle, un ensemble de problèmes. Premièrement, cette implémentation est fortement liée à la classe CustomerRepository, si cette classe (ou du moins son constructeur) change, GetOneCustomer devra changer aussi. Deuxièmement, dans cette implémentation, GetOneCustomer hérite d'une responsabilité superflue, à savoir la création du CustomerRepository.

Si l'on utilise l'injection de dépendances, la représentation finale de notre appel ressemblera plus à :

public class CustomerService {

    private CustomerRepository _repository;
    
    public Customer GetOneCustomer(int customerId){
       return new Customer(_repository.GetOneById(customerId));
    }
}

La différence, minime au demeurant, est que la résolution de la dépendance est déportée en dehors du code « métier ». En d'autres termes, on va, dans un premier temps, définir un jeu d'interfaces de façon à ce que nos différents modules puissent communiquer par un contrat. Dans un second temps, on va « injecter » dans notre objet un autre objet répondant au contrat défini.

Utiliser l'inversion de contrôle offre les avantages suivants :

• chaque système ne se concentre que sur sa ou ses tâches principales ;
• les différents systèmes ne font pas d'hypothèse sur le comportement des autres systèmes ;
• remplacer un système ne produit pas d'effets de bord sur les autres systèmes, tant que le contrat d'origine est respecté ;
• dans le cas d'une nouvelle version d'un composant (ou d'un composant alternatif, comme un changement de framework de log, par exemple), il est plus facile de changer le composant appelé.

Une utilisation que l'on rencontre régulièrement de l'injection de dépendances est l'injection d'un Mock ou d'un Stub dans le cas de tests unitaires en isolation.

De façon classique, on va distinguer deux types d'injection. Ces possibilités sont offertes par tous les langages objet. Ces types sont l'injection par une propriété (ou une méthode pour les langages n'en disposant pas), et l'injection par le constructeur.
D'autres possibilités sont disponibles, mais ces deux-ci sont celles que l'on rencontrera le plus souvent.

II-A. Injection par une propriété▲

public class CustomerService {
    private CustomerRepository _repository;
    
    public CustomerRepository Repository {
        set{
            _repository = value;
        }
    }
    
    public Customer GetOneCustomer(int customerId){
       return new Customer(_repository.GetOneById(customerId));
    }
}

public class PortfolioService{

  private ISecurityService _securityService;
  private IPortfolioRepository _portfolioRepository;

  public ISecurityService SecurityService{
    set{
      _securityService = values;
    }
  }
  
  public IPortfolioRepository PortfolioRepository{
    set{
      _portfolioRepository = values;
    }
  }
  
  public bool SavePortfolio(Portfolio pf, UserInfo user){
    if (_securityService.IsPortfolioWriteableByUser(user)){
       _portfolioRepository.Save(pf);
    } 
  }
}
]

PortfolioService tmpPortfilio = new PortfolioService();
tmpPortfilio.SavePortfolio(myPortfolio,currentUser); 
// Va remonter une NullReferenceException

II-B. Injection par le constructeur▲

public class CustomerService {
    private ICustomerRepository _repository;
    
    public CustomerService (ICustomerRepository repository) {
        _repository = repository;
    }
    
    public Customer GetOneCustomer(int customerId){
       return new Customer(_repository.GetOneById(customerId));
    }
}

II-C. En résumé▲

Les conteneurs IoC sont des outils spécifiquement conçus pour faciliter l'injection de dépendances. Originellement, ces utilitaires viennent du monde Java, mais, au fil de ces dernières années, des conteneurs IoC propres au framework .NET sont apparus, issus du monde open source aussi bien que de Microsoft.

Pour montrer un exemple le plus proche de la réalité possible, on va partir du cas métier suivant :

On veut développer un gestionnaire de Clients, avec :

• une classe d'accès aux données ClientRepository, qui implémente l'interface IclientRepository ;
• une classe métier ClientService, qui implémente l'interface IClientService. ClientService possède une dépendance sur un objet de type IClientReposiory, qui va lui fournir des données à traiter ;
• un formulaire qui utilise une interface métier IClientService

Le code pour ces trois classes aura donc la forme suivante :

public class Form1{

    public void LoadCustomerData(int customerId){
        ICustomerRepository repository = new CustomerRepository();
        ICustomerService service = new CustomerService(repository);
        Customer monClient = service.GetOneCustomer(1);
        Messagebox.Show(monClient.Name);
    }

}
            
public interface ICustomerService {
        
    public DataTable GetOneCustomer(int customerId){
       ...
    }
}
public class CustomerService {
    private ICustomerRepository _repository;
    
    public CustomerService (ICustomerRepository repository) {
        _repository = repository;
    }
    
    public Customer GetOneCustomer(int customerId){
       return new Customer(_repository.GetOneById(customerId));
    }
}

public interface ICustomerRepository {
        
    public DataTable GetOneById(int customerId){
       ...
    }
}

public class CustomerRepository {
        
    public DataTable GetOneCustomer(int customerId){
       ...
    }
}

Comme on l'avait remarqué précédemment, la classe cliente récupère la responsabilité de l'instanciation des classes qu'elle doit injecter. On va voir comment se passer de ce code.

III-A. Spring.NET▲

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="spring">
      <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
      <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
    </sectionGroup>
  </configSections>
  <spring>
    <context>
      <resource uri="config://spring/objects"/>
    </context>
    <objects xmlns="http://www.springframework.NET">
      <object name="ProductService" type="ServiceLayer.ProductService, ServiceLayer"      
              singleton="true">
        <constructor-arg index="0" ref="ProductRepository"/>
      </object>
      <object name="ProductRepository"
        type="RepositoryLayer.ProductRepository,RepositoryLayer"/>
    </objects>
  </spring>
</configuration>

IApplicationContext ctx = ContextRegistry.GetContext();
            var monClient = ((IProductService)ctx.GetObject("ProductService")).
                GetOneProductById(1);

III-B. Unity▲

<configuration>
 <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
  </configSections>
  <unity>
    <typeAliases>
      <typeAlias alias="int" type="System.Int32, mscorlib" />
      <typeAlias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager, Microsoft.Practices.Unity" />
      <typeAlias alias="IProductRepository" type="RepositoryLayer.IProductRepository,RepositoryLayer" />
      <typeAlias alias="IProductService" type="ServiceLayer.IProductService, ServiceLayer" />
    </typeAliases>
    
    <containers>
      <container>
        <types>
          <type type="IProductRepository" mapTo="RepositoryLayer.ProductRepository,RepositoryLayer">
            <lifetime type="singleton" />
          </type>
          <type type="IProductService" mapTo="ServiceLayer.ProductService, ServiceLayer">
            <lifetime type="singleton" />
            <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
              <constructor>
                <param name="repository" parameterType="IProductRepository"/>
              </constructor>
            </typeConfig>
          </type>
        </types>
      </container>
    </containers>
  </unity>
</configuration>

    IUnityContainer container = new UnityContainer();
    container.RegisterType<IProductRepository, ProductRepository>()
           .RegisterType<IProductService, ProductService>();

var monClient = container.Resolve<IProductService>().
    GetOneProductById(1);

var section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Containers.Default.Configure(container);

III-C. Ninject▲

class ProductModule : StandardModule {
    public override void Load() {
        Bind<IProductService>().To<ProductService>();
        Bind<IProductRepository>().To<ProductRepository>();
    }
}

IKernel kernel = new StandardKernel(new ProductModule());

var monClient = kernel.Get<IProductService>().
    GetOneProductById(1);

IKernel kernel = new StandardKernel(new InlineModule(
      module => module.Bind<IProductService>().To<ProductService>(),
      module => module.Bind<IProductRepository>().To<ProductRepository>()
      )
  );

III-D. StructureMap▲

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap MementoStyle="Attribute">
  <DefaultInstance
      PluginType="ServiceLayer.IProductService, ServiceLayer"
      PluggedType="ServiceLayer.ProductService, ServiceLayer" />
  <DefaultInstance
      PluginType="RepositoryLayer.IProductRepository,RepositoryLayer"
      PluggedType="RepositoryLayer.ProductRepository,RepositoryLayer" />
</StructureMap>

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
  <Assembly Name="StructureMapAttributs"/>
</StructureMap>

    [StructureMap.PluginFamily("Default")]
    public interface IProductService {
        Product GetOneProductById(int id);
    }

    [StructureMap.Pluggable("Default")]
    public class ProductService : IProductService {

        private readonly IProductRepository _repository;

        public ProductService(IProductRepository repository) {
            _repository = repository;
        }

        public Product GetOneProductById(int id) {
            return new Product(_repository.GetOneProduct(id).Rows[0]);
        }
    }
}

ObjectFactory.Initialize(clientObject =>
        {
            clientObject.ForRequestedType<IProductService>().
                TheDefaultIsConcreteType<ProductService>();
            clientObject.ForRequestedType<IProductRepository>().
                TheDefaultIsConcreteType<ProductRepository>();
        });

On a vu qu'utiliser un framework d'IoC permet de réduire les dépendances entre les différents composants de notre application, pour en augmenter la maintenabilité. Or, si on pousse la logique à l'extrême, il nous restera toujours une dépendance, quoi que l'on fasse… sur le framework d'IoC. Autant, sur un projet « standard », cela peut ne pas être un problème, autant on risque de trouver des cas pour lesquels on veut pouvoir faciliter le passage d'un framework IOC à l'autre. Par exemple, si une bibliothèque ou un framework est développé par une entité A qui utilise StructureMap, une entité B qui voudra utiliser le framework héritera d'une dépendance sur StructureMap, même si elle utilise déjà Ninject (et l'exemple n'est pas anodin, car c'est de là que tout est parti, à savoir d'une dépendance de Fluent NHibernate sur StructureMap).

Le projet CommonServiceLocator, disponible sur Codeplex, est justement la réponse à cette problématique. Il permet en effet d'utiliser une interface de plus haut niveau, et d'agir comme un pattern Adapter pour rerouter les appels au Service Locator vers le framework d'IoC choisi.

L'interface du CommonServiceLocator est très simple (voire simpliste), et ne concerne que la récupération des objets, la configuration des résolutions de dépendance restant le travail du framework d'injection. La voici dans toute sa splendeur :

namespace Microsoft.Practices.ServiceLocation
{
    public interface IServiceLocator : IServiceProvider
    {
        object GetInstance(Type serviceType);
        object GetInstance(Type serviceType, string key);
        IEnumerable<object> GetAllInstances(Type serviceType);

        TService GetInstance<TService>();
        TService GetInstance<TService>(string key);
        IEnumerable<TService> GetAllInstances<TService>();
    }
}

La communauté a déjà contribué des adaptateurs spécifiques pour un certain nombre de conteneurs (Castle Windsor, Spring .NET, Unity, StructureMap, Autofac et MEF). Ces Adaptateurs permettent, dans le cas d'un framework, de laisser l'utilisateur choisir quel framework il veut utiliser, et de créer, par exemple, un locateur spécifique à StructureMap ou à Unity, et de l'utiliser comme locateur par défaut.

Pour cela, on va, dans un premier temps, créer un Locator spécifique (à StructureMap dans cet exemple, grâce à l'adaptateur StructureMapServiceLocator disponible sur le site du projet) :

    public static class StructureMapLocator {

        public static IServiceLocator CreateServiceLocator() {
            Registry registry = new Registry();
            registry.ForRequestedType<IProductRepository>().TheDefaultIsConcreteType<ProductRepository>();
            registry.ForRequestedType<IProductService>().TheDefaultIsConcreteType<ProductService>();
            IContainer container = new Container(registry);

            return new StructureMapServiceLocator(container);
        }
    }

Puis, on va, au niveau de notre code, déclarer l'utilisation de notre locateur comme ServiceLocator actuel, et appeler la fonction GetInstance du ServiceLocator pour effectuer la résolution de type :

var structureMapLoc = StructureMapLocator.CreateServiceLocator();
ServiceLocator.SetLocatorProvider(() => structureMapLoc);

var monClient = ServiceLocator.Current.GetInstance<IProductService>().
    GetOneProductById(1);
Console.WriteLine(monClient);

Le CommonServiceLocator est une couche d'indirection supplémentaire, mais permet, s'il est bien utilisé, de changer facilement de framework IoC si le besoin s'en fait sentir (comme, par exemple, une nouvelle version du framework A, dont les performances sont nettement supérieures au framework B).

J'espère que ce petit tour d'horizon vous aura permis d'apprendre au moins deux ou trois choses (moi en tout cas, j'en ai appris plein ;) ).

Pour conclure, l'injection de dépendances est une technique très intéressante pour augmenter le degré d'indépendance des différents éléments manipulés durant un développement. Dans cet article, on a vu les grandes lignes de ce principe, et quelques frameworks permettant de le faciliter, mais ce n'est que le début du voyage. Je vous encourage donc à relever le « défi » d'incorporer dans votre prochain développement cette technique, et de voir où cela vous mène.

Un point à souligner tout de même. L'injection de dépendances n'est évidemment pas une panacée, et il faut retenir que, dans l'absolu, cette technique ne sert à rien si :

• on n'aura jamais besoin d'une autre implémentation ;
• on n'aura jamais besoin d'une configuration différente ;
• on n'aura jamais besoin d'isoler un ou plusieurs composants (et pas de tests unitaires).

Enfin, quels que soient les avantages de cette technique, la résolution est forcément légèrement plus coûteuse que la création d'un nouvel objet. Il peut donc être néfaste, dans des cas limites de créations de grandes quantités d'objets, d'utiliser l'injection de dépendances.

Toutes les sources utilisées dans cet article, ainsi que le projet (pour Visual Studio 2008) sont disponibles ici.

Je remercie toute l'équipe Dotnet de developpez pour leurs relectures attentives du document. En particulier, merci à tomlev pour sa relecture.

Si vous constatez une erreur dans le tutoriel, ou pour toute information, n'hésitez pas à me contacter par mail, ou sur le forum.