18 Sep 2012 in
ASP.NET MVC
|
Microsoft Azure
Pour un projet, j’ai du mettre en place un mode d’authentification hybride Forms / ACS (Access Control Service) au sein d’une même application ASP.NET MVC, hébergée dans Azure.
Pour la partie Forms Authentication, je me suis basé sur un custom membership provider qui travaille avec le stockage par table de Windows Azure. Vous pouvez également utiliser les Azure Storage providers disponibles sur CodePlex ou NuGet. Je ne détaillerai pas la configuration de ce type d’authentification qui a déjà été traité dans pas mal d’articles sur le net.
Je souhaitais absolument avoir un mécanisme d’authentification qui soit peu intrusif, et surtout éviter d’avoir à gérer deux types d’authentification techniquement distincts dans mon code (si je suis en ACS alors la déconnexion se fait comme cela, si je suis en Forms alors …). Du coup, j’ai décidé d’utiliser ACS uniquement comme mécanisme d’authentification et du coup comme autorité
d’identification des mes utilisateurs.
Pour se faire, j’ai tout d’abord configuré mon espace de noms ACS sur le portail d’administration Windows Azure. Pour voir comment faire cela pas à pas, je vous invite à lire ce billet sur le blog de Léo.
Une fois ACS configuré, il est possible de gérer l’authentification via ACS (et donc Windows Identity Foundation) de plusieurs manières : la première, en utilisant le fichier Web.config et en configurant les bons HTTP module fournis avec le SDK WIF. Lors de la callback d’ACS (après authentification Windows Live, Facebook ou Yahoo…) les modules se chargeront automatiquement de récupérer l’identité de l’utilisateur ainsi que de retourner ses claims
(propriétés qui identifient l’utilisateur, telles que son identifiant, son email, son nom… en fonction de ce qui a été configuré sur ACS).
L’autre solution consiste à ne pas utiliser la configuration automatique de WIF et de catcher manuellement
la réponse d’ACS après que l’utilisateur soit authentifié. Pour cela, il suffit d’écrire un peu de code, mais rien de bien méchant !
Avant tout, il est nécessaire d’ajouter deux références au projet : Microsoft.IdentityModel.dll (disponible dans le GAC après avoir installé le SDK WIF) et System.IdentityModel.dll.
Il faut commencer par vérifier que la requête HTTP est bien issue d’une callback d’ACS. Pour se faire, on utilise le module WSFederationAuthenticationModule qui fournit des outils pour interpréter les réponses d’ACS en mode WS-Federation :
WSFederationAuthenticationModule wsFedAuthModule = new WSFederationAuthenticationModule();
if (!wsFedAuthModule.IsSignInResponse(request))
throw new HttpException(403, "forbidden");
Ensuite, il est possible de récupérer la réponse sous la forme d’un objet de type SignInResponseMessage :
var signInResponseMessage = wsFedAuthModule.GetSignInResponseMessage(System.Web.HttpContext.Current.Request);
La récupération des claims renvoyé par le STS (Secure Token Service) d’ACS se fait ensuite à l’aide du WSFederationSerializer, qui permet notamment de récupérer le secure token de la réponse :
var serializationContext =
new WSTrustSerializationContext(SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager());
var secureTokenResponse = new WSFederationSerializer().CreateResponse(signInResponseMessage, serializationContext);
La réponse qui est récupérée contient le token de sécurité renvoyé par ACS. Celui-ci contient les différentes informations relative à l’utilisateur et est chiffré. Il est nécessaire d’utiliser un Saml2SecurityTokenHandler afin d’accéder aux informations du token. Avant, il est nécessaire de récupérer l’emprunte du certificat utilisé par ACS, l’espace de nom ACS, ainsi que la liste des URIs autorisées à travailler avec ACS (en fonction de votre configuration, je vous renvoie vers l’article de Léo évoqué plus tôt) :
ConfigurationBasedIssuerNameRegistry issuers = new ConfigurationBasedIssuerNameRegistry();
string certificateTumbprint = "<certificat tumbprint>";
var ascNamespace = "https://votrenamespace.accesscontrol.windows.net/";
issuers.AddTrustedIssuer(certificateTumbprint, ascNamespace);
Saml2SecurityTokenHandler tokenHandler = new Saml2SecurityTokenHandler
{
CertificateValidator = X509CertificateValidator.None
};
SecurityTokenHandlerConfiguration config = new SecurityTokenHandlerConfiguration
{
CertificateValidator = X509CertificateValidator.None,
IssuerNameRegistry = issuers
};
config.AudienceRestriction.AllowedAudienceUris.Add(new Uri("http://127.0.0.1"));
tokenHandler.Configuration = config;
Maintenant que le token handler est correctement configuré il ne reste qu’à utiliser un simple XmlReader pour lire le security token et en extraire la collection de **ClaimsIdentity**
qu’il transporte :
using (var reader = XmlReader.Create(new StringReader(secureTokenResponse.RequestedSecurityToken.SecurityTokenXml.OuterXml)))
{
SecurityToken token = tokenHandler.ReadToken(reader);
ClaimsIdentityCollection claimsIdentity = tokenHandler.ValidateToken(token);
}
Chaque ClaimsIdentity contenu dans la collection possède alors une collection Claims, retournant chacun des claim associé à l’utilisateur qui s’est connecté. Il ne reste qu’à implémenter votre propre logique pour créer le cookie de session de l’utilisateur (à l’aide de la méthode SetAuthCookie de la classe FormsAuthentication, par exemple).
Il est donc possible d’avoir un contrôle vraiment fin sur l’authentification d’un utilisateur via ACS, permettant ici d’inter-opérer simplement avec un autre mécanisme d’authentification !
A bientôt ![image](/images/authentification-hybride-forms-et-acs-dans-une-application-aspnet-mvc-hebergee-dans-azure/ba0b76a6-45ff-45a3-a9d1-28b12ac36d90.jpg)
read more
12 Sep 2012 in
ASP.NET MVC
Dans mon article précédent, je vous expliquais comment mettre en place les nouveaux contrôleurs Web API
pour exposer vos données de manière RESTful
. Je m’étais arrêté à la partie ASP.NET MVC Web API pure. Dans cet article, je souhaite fournir un exemple d’interface graphique venant consommer ces APIs.
J’ai choisi de développer l’interface en HTML/jQuery pur au sein du même projet que celui hébergeant mon API contrôleur. Ce qu’il faut bien comprendre ici, c’est que j’aurai pu faire le choix de n’importe quelle technologie capable d’envoyer une requête HTTP et de traiter du JSON (du texte, au final) : Windows Phone, Windows 8, iPhone, PHP… Bref, n’importe quelle plateforme de développement suffisamment récente (ou presque!).
###
Définition de l’interface graphique
L’interface graphique que j’ai choisi est ultra simple :
<div style="margin: 20px">
## Consommation des WEB Api
### Liste des requêtes
<a id="showRequestsLink" title="afficher les requêtes" href="#">afficher les requêtes</a>
<div id="requestsList">
### Ajouter une requête
<div id="addFormContainer">
<form id="addRequestForm">
Titre : <input type="text" name="Title" id="Title" />
Description : <input type="text" name="Description" id="Description" />
<input type="hidden" name="Id" id="Id" value="" />
<input type="button" id="addRequestButton" value="Ajouter" />
</form>
Voilà ce que cela donne dans un navigateur :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-2/5a711f69-815d-43ee-94ee-ef266dccf67a.jpg)
Ensuite, tout se passe en ajax (et en HTTP!!).
Affichage de la liste des requêtes
Lorsque l’utilisateur clique sur le lien pour afficher la liste des requêtes, il est nécessaire de faire un GET
sur l’URL /api/featurerequest, ce qui aura pour effet d’appeler l’action Get de l’ApiController développé dans l’article précédent.
function updateRequests() {
$.get("/api/featurerequests", function (requests) {
if (requests.length == 0) {
$("#requestsList").html("aucune requête dans la base de données
");
}
else {
$("#requestsList").html("");
$("#requestTemplate").tmpl(requests).appendTo("#requestsList");
handleLinksClicks();
}
});
}
$(document).ready(function () {
$("#showRequestsLink").click(function (evt) {
updateRequests();
});
});
L’appel en GET de l’url /api/featurerequests retourne directement un tableau d’objet JavaScript qui possède les mêmes propriétés que l’objet server FeatureRequest
, celui-ci ayant automatiquement été sérialisé en JSON par le moteur Web API. Notez au passage que j’utilise ici le plugin jQuery tmpl, permettant d’effectuer un rendu à partir d’un template HTML. Vous pouvez récupérer directement ce plugin via la console Nuget de Visual Studio :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-2/643c3277-3b94-4915-8885-f8ef20b4c811.jpg)
Voilà la structure du template que j’ai défini :
<script id="requestTemplate" type="text/html">
- [Détail](#) | [Détail](#) | [Détail](#)
</script>
Note : chacune des propriétés de l’objet JSON peut être appelé à l’aide de la notation au sein du template ! (au passage, il s’agit d’un plugin jQuery développé par Microsoft
, on sent l’influence du binding XAML)
###
Ajouter/Mettre à jour une requête dans la base de données
Pour ajouter une nouvelle requête dans la base de données, il suffit de poster le formulaire sur l’URL /api/featurerequests. La requête sera alors automatiquement traitée par l’action qui lui correspond dans le contrôleur développé. Pour mettre à jour une requête, il suffit d’envoyer une requête HTTP PUT sur la même URL, avec les données du formulaire, sérialisées :
$("#addRequestButton").click(function (evt) {
evt.preventDefault();
var addRequestForm = $("#addRequestForm");
if ($("#Id").val() != "") {
$.ajax({
url: "/api/featurerequests/" + $("#Id").val(),
type: "PUT",
data: addRequestForm.serialize(),
success: function () {
updateRequests();
$("#Id").val("");
$("#Title").val("");
$("#Description").val("");
$("#addRequestButton").val("Ajouter");
},
error: function () {
alert("Erreur lors de la mise à jour");
}
});
}
else {
$.post("/api/featurerequests", addRequestForm.serialize())
.success(function (result) {
$("#Title").val("");
$("#Description").val("");
updateRequests();
})
.error(function () {
alert("Une erreur s'est produite!");
});
}
});
###
Pour récupérer une information propre à une requête, il suffit d’envoyer une requête HTTP GET à l’url /api/featurerequests/id :
$(".request-detail-link").click(function () {
var dataId = $(this).data("id");
var url = "/api/featurerequests/" + dataId;
$.get(url, function (jsonResult) {
alert(JSON.stringify(jsonResult));
});
});
Suppression d’une requête
Cette fonctionnalité est similaire à la récupération d’informations propres à une requête, à la différence près qu’il faut envoyer une requête HTTP DELETE :
$(".request-delete-link").click(function () {
var dataId = $(this).data("id");
if (confirm("Êtes-vous sûr de supprimer cette requête ?")) {
$.ajax({
url: "/api/featurerequests/" + dataId,
type: "DELETE",
success: function () {
alert("La requête a été supprimée");
updateRequests();
}
});
}
});
Conclusion / Résumé
L’important ici n’était pas tant le code JavaScript / HTML, mais plutôt de voir comment consommer très simplement les données à l’aide de requête HTTP et donc potentiellement depuis n’importe quelle plateforme récente ![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-2/3db188c9-eb87-4ef2-9f41-8f240fbbed01.jpg)
Ci-dessous un résumé des différentes requêtes / verbes et de leurs actions respectives dans le contrôleur :
-
GET /api/featurerequests : GetFeatureRequests –> retourne la liste des requêtes
-
GET /api/featurerequests/id : GetFeatureRequest –> retourne une requête en particulier
-
POST /api/featurerequests : PostFeatureRequest –> ajouter une requête dans la base
-
PUT /api/featurerequests : PutFeatureRequest –> mise à jour d’une requête dans la base
-
DELETE /api/featurerequests/id : DeleteFeatureRequest –> suppression d’une requête de la base
Vous pouvez récupérer le code source ici.
A bientôt ! ![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-2/8a8d04ae-9710-4b08-bf7e-74fad62e6b2e.jpg)
read more
17 Aug 2012 in
ASP.NET MVC
Introduction
ASP.NET MVC 4 a été rendu disponible par Microsoft il y a peu et apporte son lot de nouveautés. Parmi celles-ci, on constate l’apparition d’une nouvelle brique : ASP.NET Web API. Il s’agit d’un Framework qui permet de développer rapidement et simplement des services HTTP pour la mise à disposition de données cross-plateforme et le développement d’application RESTful !
Dans ce post, je vous propose de créer une application reposant sur ce Framework et permettant de poster des requêtes de fonctionnalités / feedback pour un produit, comme le fait par exemple Uservoice.com (en beaucoup plus simple, évidemment).
Avant de commencer, il vous faut installer ASP.NET MVC 4. Pour cela, rendez-vous sur cette page et cliquez sur Install ASP.NET MVC 4.
Note : il est possible de développer des applications ASP.NET MVC 4 / ASP.NET Web API aussi bien dans Visual Studio 2010 que 2012, avec le .NET Framework 4.0 ou 4.5. Pour ma part, j’utiliserai Visual Studio 2012 et le .NET Framework 4.5.
Création du projet
Dans Visual Studio, créez un nouveau projet Web, de type ASP.NET MVC 4 Web Application :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/b40426c4-4c19-4a0a-8825-45cfc6813b17.jpg)
Dans la fenêtre qui suit, choisissez un modèle de projet de type Web API. Gardez Razor comme moteur de vue, et validez la création du projet :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/893325b2-91b2-4a75-8867-1fb4157da6ea.jpg)
Analyse de la solution
Avant d’ajouter la moindre ligne de code au projet, nous allons nous intéresser à ce qui a été généré par Visual Studio. S’il s’agit de votre premier projet ASP.NET MVC 4, vous devez remarquer qu’un nouveau dossier App_Start est présent dès la création du projet. Celui-ci contient un ensemble de classes utilisées pour l’initialisation de l’application, dans la méthode Application_Start du fichier Global.asax!
Visual Studio a également créé deux contrôleurs :
HomeController : il s’agit d’un contrôleur ASP.NET MVC classique, composé d’une action Index pour renvoyer l’utilisateur sur la page d’accueil lorsqu’il se connecte sur le site. C’est ce contrôleur et cette action qui sont appelés lorsque vous lancez le site web en débogue.
ValuesController : il s’agit d’un contrôleur ASP.NET Web API d’exemple. Celui-ci est composé de 5 méthodes permettant d’adresser différentes actions : récupérer une liste de valeur, récupérer une valeur par son id, ajouter une valeur, modifier une valeur, supprimer une valeur. Remarquez qu’à chacune de ces actions est associé un verbe HTTP : GET pour la récupération, POST pour l’ajout, PUT pour la modification et DELETE pour la suppression.
// GET api/values
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
// GET api/values/5
public string Get(int id)
{
return "value";
}
// POST api/values
public void Post([FromBody]string value)
{
}
// PUT api/values/5
public void Put(int id, [FromBody]string value)
{
}
// DELETE api/values/5
public void Delete(int id)
{
}
Lancez l’application en débogue en appuyant sur F5.
Dans la barre d’adresse du navigateur, connectez-vous sur [/api/values”>http://localhost:/api/values](http://localhost:/api/values) :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/f53e0ce5-e3a4-45f3-a29c-51381e3b8784.jpg)
Vous pourrez alors constater que votre navigateur vous propose de télécharger un fichier .json
contenant la liste de valeurs retournées par la méthodes Get du contrôleur ValuesController, au format JSON : [“value1”,”value2”].
ASP.NET Web API utilise le même principe de routes qu’ASP.NET MVC, par défaut, toutes les URLs contenant /api/quelque chose sont redirigé vers un contrôleur de type ApiController. Ensuite, la résolution de l’action (méthode) et de ses éventuels paramètres fonctionne comme ASP.NET MVC. Le verbe HTTP utilisé est également très important puisque déterminant la méthode à appeler.
La route api
par défaut est définie dans le fichier WebApiConfig du dossier** App_Start** et est initialisée dans le fichier Global.asax, au démarrage de l’application :
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
Création du modèle
Dans cette partie, nous allons créer le modèle chargé de représenter une requête de fonctionnalité dans l’application d’exemple. Faites un clic droit sur le dossier Models dans l’explorateur de solution et ajoutez une classe FeatureRequest :
public class FeatureRequest
{
public int Id { get; set; }
public string Title { get; set; }
public string Description { get; set; }
}
Compilez simplement l’application afin que les outils ASP.NET MVC puissent détecter cette nouvelle classe dans la suite.
Ajout d’un nouveau contrôleur Web API
Faites un clic droit sur le dossier Controllers dans l’explorateur de solution et choisissez d’ajouter un nouveau contrôleur. Dans la fenêtre qui s’ouvre, nommez le FeatureRequestsController. Dans les options de scaffholding, choisissez le template API controller with read/write actions, using Entity Framework, le Model FeatureRequest et de créer un nouveau DataContext EntityFramework pour accéder aux données :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/c692f11d-9129-463d-82cf-73c07464b684.jpg)
Nommez votre contexte EF dans la fenêtre qui s’affiche :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/0120fd6a-2cd5-47a7-b4dd-0a6115f5f221.jpg)
Validez en cliquant sur OK puis Add.
Les outils ASP.NET MVC génèrent alors deux classes pour vous : FeatureRequestController.cs (dossier Controllers) et FeatureRequestWebAPIContext.cs (dossier Models). La première représente le nouveau contrôleur alors que la seconde représente le contexte Entity Framework pour l’accès aux données. Celui-ci est utilisé dans le contrôleurs, dans les différentes méthodes générées pour la récupération de la liste des requêtes, d’une requête en particulier, la création d’une requête, la modification d’une requête et enfin la suppression d’une requête.
ublic class FeatureRequestsController : ApiController
{
private FeatureRequestWebAPIContext db = new FeatureRequestWebAPIContext();
// GET api/FeatureRequests
public IEnumerable<FeatureRequest> GetFeatureRequests()
{
return db.FeatureRequests.AsEnumerable();
}
// GET api/FeatureRequests/5
public FeatureRequest GetFeatureRequest(int id)
{
FeatureRequest featurerequest = db.FeatureRequests.Find(id);
if (featurerequest == null)
{
throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound));
}
return featurerequest;
}
// PUT api/FeatureRequests/5
public HttpResponseMessage PutFeatureRequest(int id, FeatureRequest featurerequest)
{
if (ModelState.IsValid && id == featurerequest.Id)
{
db.Entry(featurerequest).State = EntityState.Modified;
try
{
db.SaveChanges();
}
catch (DbUpdateConcurrencyException)
{
return Request.CreateResponse(HttpStatusCode.NotFound);
}
return Request.CreateResponse(HttpStatusCode.OK);
}
else
{
return Request.CreateResponse(HttpStatusCode.BadRequest);
}
}
// POST api/FeatureRequests
public HttpResponseMessage PostFeatureRequest(FeatureRequest featurerequest)
{
if (ModelState.IsValid)
{
db.FeatureRequests.Add(featurerequest);
db.SaveChanges();
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.Created, featurerequest);
response.Headers.Location = new Uri(Url.Link("DefaultApi", new { id = featurerequest.Id }));
return response;
}
else
{
return Request.CreateResponse(HttpStatusCode.BadRequest);
}
}
// DELETE api/FeatureRequests/5
public HttpResponseMessage DeleteFeatureRequest(int id)
{
FeatureRequest featurerequest = db.FeatureRequests.Find(id);
if (featurerequest == null)
{
return Request.CreateResponse(HttpStatusCode.NotFound);
}
db.FeatureRequests.Remove(featurerequest);
try
{
db.SaveChanges();
}
catch (DbUpdateConcurrencyException)
{
return Request.CreateResponse(HttpStatusCode.NotFound);
}
return Request.CreateResponse(HttpStatusCode.OK, featurerequest);
}
protected override void Dispose(bool disposing)
{
db.Dispose();
base.Dispose(disposing);
}
}
Note : remarquez à nouveau que le verbe HTTP utilisé entre en jeu dans la convention de nommage des actions du contrôleur !
Si vous exécutez le site web en débogue et vous connectez à l’adresse [/api/featurerequests”>http://localhost:/api/featurerequests](http://localhost:/api/featurerequests), votre navigateur devrait vous proposer de télécharger un fichier JSON contenant la liste des requêtes de fonctionnalités (vide pour le moment, évidemment !) :
![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/bfb4863b-8188-451c-ba6a-1ce463c1b445.jpg)
Conclusion
Dans cette première partie, vous avez mis en place la structure de l’application ASP.NET Web API pour la gestion des requêtes de fonctionnalités.
Dans le prochain article, nous développeront l’interface graphique qui sera en charge de consommer ce service RESTful !
A bientôt ![image](/images/aspnet-mvc-premiers-pas-avec-les-aspnet-web-api-partie-1/32431328-1be7-4fdf-bb2a-49c58e5bb233.jpg)
read more
11 Mar 2012 in
ASP.NET MVC
Dans ce post, je souhaite revenir sur une bonne pratique que Rui et moi-même avons évoqué lors de notre session sur Rui le mois dernier : l’isolation de l’initialisation d’une application ASP.NET MVC.
En effet, le template par défaut de création de projet ASP.NET MVC de Visual Studio concentre tout le code dans un seul et même projet ce qui peut poser des problèmes de maintenabilité et/ou d’organisation, notamment sur un projet conséquent.
L’idée est de créer un Bootstrapper, c’est à dire une entité qui soit capable d’initialiser l’application, charger les différentes dépendances via un conteneur IoC (Unity, dans cet exemple), enregistrer les différentes routes, areas (etc…) qui composent l’application.
Voilà l’architecture globale de ma solution d’exemple (sources disponibles en bas de page!) :
![image](/images/aspnet-mvc-bonnes-pratiques-creation-dun-bootstrapper-ou-comment-isoler-linitialisation-dune-application/8f8cbfc8-1515-48ef-a563-71eb36cb012b.jpg)
- Sample.Bootstrapper est une bibliothèque de classe qui référence : System.Web, System.Web.Mvc et System.Web.Routing et Microsoft.Practices.Unity, afin d’être en capacité d’initialiser l’application
- Sample.Services est une bibliothèque de classes qui défini un service tout simple, représenté par une interface et une implémentation concrète.
- Sample.Web est l’application ASP.NET MVC
Vous l’avez surement compris, l’essentiel du travail va se concentrer dans le projet Sample.Bootstrapper.
En premier lieu, le UnityBootstrapper : il s’agit d’une classe qui expose un conteneur Unity au reste de l’application, c’est celui-ci qui est utilisé pour la résolution des dépendances au runtime :
public class UnityBootstrapper
{
private UnityBootstrapper()
{
}
private static void InitializeContainer(IUnityContainer container)
{
container.RegisterType<ISampleService, LoremIpsumSampleService>();
}
private static readonly object _syncRoot = new object();
private static IUnityContainer _container;
public static IUnityContainer Container
{
get
{
if (_container == null)
{
lock (_syncRoot)
{
if (_container == null)
{
_container = new UnityContainer();
InitializeContainer(_container);
}
}
}
return _container;
}
}
}
On expose ici le conteneur Unity racine de l’application sous la forme d’un Singleton. Les registers sont fait dans le code ou dans le fichier Web.config, selon le besoin.
Afin de pouvoir utiliser l’injection de dépendance dans l’application, il faut configurer le moteur MVC pour utiliser ce conteneur Unity lors de la résolution des contrôleur. Pour cela, on passe par une implémentation de l’interface IControllerActivator, ici la classe UnityControllerActivator :
public class UnityControllerActivator : IControllerActivator
{
private readonly IUnityContainer _container;
public UnityControllerActivator(IUnityContainer unityContainer)
{
_container = unityContainer;
}
public IController Create(System.Web.Routing.RequestContext requestContext, Type controllerType)
{
return _container.Resolve(controllerType) as IController;
}
}
Il ne reste plus qu’à définir la bonne controller factory afin que le UnityControllerActivator soit utilisé.
Avant cela, j’attire votre attention sur la dernière classe qui se trouve dans le projet Sample.Bootstrapper : MvcApplication. Il s’agit en réalité de la classe d’application (qui dérive de System.Web.HttpApplication) et qui se trouve par défaut liée au fichier Global.asax, lors de la création du projet. Le fait de déporter cette classe dans un projet externe permet de bien isoler le chargement de l’application et d’y définir les différentes routes, areas ou comportement du Framework, par exemple, demander au ControllerBuilder d’aller utiliser notre propre IControllerActivator :
public class MvcApplication : HttpApplication
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}/{action}",
new { controller = "Sample", action = "Index" }
);
}
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterGlobalFilters(GlobalFilters.Filters);
RegisterRoutes(RouteTable.Routes);
var controllerFactory = new DefaultControllerFactory(
new UnityControllerActivator(UnityBootstrapper.Container));
ControllerBuilder.Current.SetControllerFactory(controllerFactory);
}
}
Il ne reste plus qu’à lier cette classe au fichier Global.asax afin qu’elle soit prise en compte au démarrage de l’application. Pour cela, il suffit d’ouvrir le fichier à l’aide de l’éditeur XML de Visual Studio, et de modifier la définition de la classe d’application :
<%@ Application Codebehind="Global.asax.cs" Inherits="Sample.Bootstrapper.MvcApplication" Language="C#" %>
Et voilà, le tour est joué! Les sources sont disponibles ici : http://juliencorioland.blob.core.windows.net/publicfiles/Sample-Bootstrapper.zip
A bientôt ![image](/images/aspnet-mvc-bonnes-pratiques-creation-dun-bootstrapper-ou-comment-isoler-linitialisation-dune-application/42bbc110-92e7-44cc-8552-595c4ba6161f.jpg)
Julien
read more
11 Mar 2012 in
ASP.NET MVC
|
Windows Phone
Vous n’êtes certainement pas passé à côté de cette information : les webcasts de l’édition 2012 des Microsoft Techdays sont en ligne ! Il est possible de les visionner à cette adresse : http://www.microsoft.com/france/mstechdays/programmes/parcours.aspx.
J’en profite pour vous donner les pointeurs vers les webcasts, slides et codes source des sessions que j’ai eu le plaisir d’animer cette année :
Architecture, bonnes pratiques et recettes pour la réussite de vos projets ASP.NET MVC
La dure lutte du développeur : 10 trucs pratiques pour une application mobile bien léchée
Enseigner les technologies Microsoft, un exemple avec Windows Phone
Bon visionnage !
Julien
read more