févr. 17 2011

[ASP.NET MVC] Nouveautés MVC 3 Part 4 - Meilleur support de l'injection de dépendances

Category: ASP.NET | ASP.NET MVC | ASP.NET MVC 3Nicolas Esprit @ 12:22

L'injection de dépendances, et les avantages que cette technique apporte, devrait normalement être un concept connu de la plupart des développeurs. Pour un bref rappel, cette technique consiste en la délégation de la résolution d'une dépendance par un composant à l'exécution, et non plus à la compilation. Ceci permet de diminuer le couplage entre les différentes entités de l'application, et donc, par exemple, de faciliter les tests unitaires. Cette technique et les logiciels qui s'y rapportent ont déjà été évoqués dans cet article : Injection de dépendances en .NET.

Ce billet fait suite à la série sur les nouveautés d'ASP.NET MVC 3 écrit conjointement avec Philippe Viallate. Vous pouvez consulter les précédents billets :

Dans les versions précédentes du Framework MVC, il n'était pas particulièrement plus aisé de mettre en place l'injection de dépendances qu'avec Web Forms (ou Winform), ce qui était navrant, vu que MVC est très orienté test unitaire, et que l'injection de dépendance est très utilisée dans ce cadre. Il était en effet nécessaire, pour pouvoir injecter nos services, d'ajouter une certaine quantité de code de « plomberie » de façon à pouvoir gérer ce scénario de façon relativement transparente.

La version 3 corrige cette lacune, et l'injection de dépendances fait maintenant partie des fonctionnalités fondamentales du Framework. En effet, le Framework inclut dorénavant une localisation unique dans laquelle les dépendances à résoudre vont être cherchées. Cette fonctionnalité se rapproche du patron de conception Service Locator.

Attention, MVC3 ne fournit pas de Framework d'injection de dépendances, mais offre des points d'extensions pour permettre de « brancher » facilement un Framework existant.

 

Interface IDependencyResolver

Cette nouvelle interface ajoute un niveau d'indirection au-dessus des autres Frameworks, dans le but de standardiser leur configuration. L'interface IDependencyResolver est tout ce qu'il y'à de plus simple. Elle se présente en effet ainsi :

namespace System.Web.Mvc {
public interface IDependencyResolver {
object GetService(Type serviceType);
IEnumerable<object> GetServices(Type serviceType);
}
}
 

Pour que MVC 3 utilise un Framework d'injection de dépendances, il nous suffit donc de créer (ou de réutiliser, il y a de fortes chances pour que la plupart de ces Frameworks proposent une classe de ce type très vite) une classe implémentant l'interface, et d'appeler, au niveau de la méthode Application_Start, la méthode DependencyResolver.SetResolver.

Nous allons, pour l'exemple, utiliser la classe StructureMapDependencyResolver décrite par Steve Smith :

public class StructureMapDependencyResolver : IDependencyResolver
{
public StructureMapDependencyResolver(IContainer container)
{
_container = container;
}

public object GetService(Type serviceType)
{
if (serviceType.IsAbstract || serviceType.IsInterface)
{
return _container.TryGetInstance(serviceType);
}
return _container.GetInstance(serviceType);
}

public IEnumerable<object> GetServices(Type serviceType)
{
return _container.GetAllInstances<object>()
.Where(s => s.GetType() == serviceType);
}

private readonly IContainer _container;
}
 

Maintenant que nous avons notre classe StructureMapDependencyResolver, il ne nous reste plus qu'à ajouter cette ligne :

DependencyResolver.SetResolver(new StructureMapDependencyResolver(new Container())) ;

pour bénéficier de l'injection de dépendance de façon quasiment transparente.

 

Utilisation du DependencyResolver

En effet, pour revenir à nos exemples précédents, nous allons légèrement refactoriser notre code, de façon à ce que notre classe UserManager soit injectée depuis le DependencyResolver.

public class UserManager
{
private readonly UserRepository _repository;
public bool ContainsLogin (string login)
{
return _repository.Any(user => user.Login.Equals(login));
}
}

On va donc commencer par définir notre interface IUserManager :

public inteface IUserManager{
public bool ContainsLogin();
}
 

Puis modifier la classe UserManager pour lui faire implémenter l'interface IUserManager :

public class UserManager : IUserManager
{
// le reste ne change pas
}
 

On va ensuite, configurer notre conteneur, de la façon suivante :

IContainer container = new Container(x =>
{
x.For<IUserManager>().Use<UserManager>();
});
DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));
 

Notre conteneur est prêt, il nous faut maintenant modifier notre classe UserController, de façon à passer en paramètre une interface IUserManager, et modifier la méthode CheckLogin, qui va utiliser cet objet.

public class UserController : Controller
{
private readonly IUserManager _manager;

public UserController(IUserManager manager)
{
_manager = manager;
}

public ActionResult CheckLogin(string login)
{
return Json(!_manager.ContainsLogin(login), JsonRequestBehavior.AllowGet);
}

// reste de la classe
}
 

Et c'est tout ! Au moment où le contrôleur est appelé, le Framework va appeler le DependencyResolver, et récupérer le type concret UserManager.

Dans le cas que l'on vient de voir, le Framework nous aide, en ajoutant les appels nécessaires de façon silencieuse. Il y a cependant des cas où l'on voudra appeler directement le DependencyResolver, ce qui se fait simplement en appelant la méthode GetService<T> du DependencyResolver actif :

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
if (DependencyResolver.Current.GetService<IUserManager>().ContainsLogin(Login))
yield return new ValidationResult("Ce login existe déjà");
}

 

Nouvelles interfaces IControllerActivator et IViewPageActivator

Toujours dans l'idée d'ajouter des possibilités d'extensions du Framework, deux nouvelles interfaces ont été ajoutées. L'idée de ces interfaces est de permettre aux développeurs de gérer très précisément la façon dont un contrôleur (ou une vue pour IViewPageActivator) est instancié grâce à l'injection de dépendances.

Ces deux interfaces sont relativement simples, vu qu'elles demandent simplement d'implémenter une méthode Create.

public interface IControllerActivator 
{
IController Create(RequestContext requestContext, Type controllerType);
}

public interface IViewPageActivator
{
object Create(ControllerContext controllerContext, Type type);
}
 
Implémenter ces classes nous permettra de contrôler le scénario de résolution de dépendance en nous basant sur le DependencyResolver. On pourrait éventuellement vouloir ajouter des logs ou tout autre scénario alternatif... On pourrait par exemple faire ceci :
public class StructureMapControllerActivator : IControllerActivator 
{
public IController Create(RequestContext requestContext, Type controllerType){
// logger l'appel à Create
return (IController)DependencyResolver.Current.GetService<controllerType>();
}
}

public class StructureMapViewPageActivator : IViewPageActivator
{
public object Create(ControllerContext controllerContext, Type type){
// logger l'appel à Create
return DependencyResolver.Current.GetService<type>();
}
}
 
Il nous reste néanmoins à enregistrer nos activateurs dans le DependencyResolver, de la façon suivante :
IContainer container = new Container(x =>
{
x.For<IViewPageActivator>().Use<StructureMapViewPageActivator>();
x.For<IControllerActivator>().Use<StructureMapControllerActivator>();
});
DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));

Tags: , , ,

Commentaires

1.
pingback topsy.com says:

Pingback from topsy.com

Twitter Trackbacks for
        
        [ASP.NET MVC] Nouveautés MVC 3 Part 4 - Meilleur support de l'injection de dépendances
        [nicolasesprit.com]
        on Topsy.com

2.
trackback ASP.NET Français Blogs says:

[ASP.NET MVC] Nouveautés MVC 3 Part 10 - Upgrader ses projets ASP.NET MVC 2 vers MVC 3

Avant de mettre fin à cette série de billet sur les nouveautés d'ASP.NET MVC

Les commentaires sont clos