Quand les relations ne peuvent être pleinement décrites par les annotations 185

Lors que vous définissez une relation, parfois, elle est plus complexe qu’il n’y parait et les annotations ne suffisent pas à la décrire proprement, ou alors il faut se torturer un peu l’esprit pour y arriver.

C’est à ce moment-là qu’intervient la FluentAPI. Je vais vous présenter deux cas ”typiques”

qui vous demanderont d’utiliser la FluentAPI.

Le premier cas, on peut le représenter très simplement sous la forme d’un schéma :

Sauf qu’il est tout à fait possible que l’instance C de départ et celle d’arrivée soient... une seule et unique instance. Si vous pensez que ça n’arrive pas dans votre cas précis, souvenez vous de la loi de Murphy : ”s’il existe une manière pour que l’action en cours se termine par une catastrophe, alors, ça finira par arriver”.

Maintenant, imaginez que vous avez besoin de supprimer l’entité A.

Par défaut, ce genre de relation entraine une suppression en cascade. Donc quand Entity Framework enverra la commande SQL associée à la suppression de A, C va être détruite. Mais du coup, B aussi. Et du coup A aussi, et du coup... attendez, on a déjà supprimé A ? Donc, quand on a demandé la suppression de C, la base de donnée n’était plus cohérente. Donc, on ne peut pas appliquer ”supprimer C”, comme ”supprimer C” a été demandé par ”supprimer B”, on ne peut pas non plus demander ”supprimer B” ni ”supprimer A”.

Plus globalement, cette situation peut arriver selon deux schémas : le cycle (cercle) et le diamant (losange). Il faudra donc décrire ce qu’il faut faire pour briser cette figure.

http://zestedesavoir.com/media/galleries/304/1638bc6d-c528-4306-ba96-4ddc8767d725.png.960x960_q85.jpg

Figure 12.4. – Relation en losange

La solution la plus simple est de décider une entité dont la suppression n’engendrera pas de suppression en cascade. Le problème c’est que cela génèrera la possibilité que l’entité liée ne soit liée à rien. Il faudra donc dire que la relation est ”optionnelle”.

Pour cela, il faudra aller dans le fichier qui contient notre contexte de données. Nous allons y surcharger la méthode OnModelCreating, comme ceci :

1 public class ApplicationDbContext : IdentityDbContext<ApplicationUser>

2 {

3 public ApplicationDbContext()

4 : base("DefaultConnection", throwIfV1Schema: false)

5 {

67 }

8 protected override void OnModelCreating(DbModelBuilder modelBuilder)

9 {

10 base.OnModelCreating(modelBuilder);

11 }

12 }

Listing 52 – Surcharge de la méthode OnModelCreating

À l’intérieur de cette méthode, nous allons utiliser les possibilités du DbModelBuilder .

III. Gérer la base de données avec Entity Framework Code First

1 modelBuidler.Entity<A>()

2 .HasMany(obj => obj.BProperty)

3 .WithOptional(objB -> objB.AProperty)

4 .WillCascadeOnDelete(false);// on dit explicitement qu'il n'y a pas de suppression en cascade

Lorsque vous recréerez une migration, le code de génération de la base de données sera amendé avec cette gestion des conflits.

Nous sommes arrivés à la fin de la troisième partie et j’ai une bonne nouvelle pour vous : vous avez toutes les bases pour créer un site dynamique et efficace avec C# et ASP.NET MVC.

Il vous reste néanmoins beaucoup de choses à découvrir pour améliorer les performances et les fonctionnalités de votre site.

Allons plus loin avec ASP.NET

13. Sécurité et gestion des utilisateurs

Jusqu’à maintenant, nous avons géré notre site sans nous soucier d’un problème majeur : l’utilisateur doit-il être enregistré pour envoyer des postes ou des commentaires ?

C’est là qu’intervient cette partie. Nous vous guiderons pas à pas pour mettre en place une gestion complète des autorisations liées à chaque utilisateur. Les deux mots clef de cette partie sont authentification etautorisation.

13.1. Authentifier un utilisateur, le login et le mot de passe

Lorsque vous naviguez sur un site web, il est fort probable que vous tombiez sur un formulaire qui vous demande votre nom d’utilisateur (le login, qu’on peut traduire par identifiant en français) et votre mot de passe²³.

Cette fonctionnalité est très simple à mettre en place : par défaut ASP.NET vous fournit toutes les bases pour créer les modèles associés à la fonctionnalité d’authentification par mot de passe.

i

Le saviez vous ? Le mot ”authentification” se distingue du mot ”identification” par le fait qu’une authentification assure que la personne est bien celle qu’elle prétend être. À l’opposé, une simple identification permet à la personne de déclarer qui elle est. C’est pour ça que vous avez un ”identifiant” et un ”mot de passe”. Le premier vous permet de déclarer votre identité, le second, comme il n’est connu que de vous (même pas de la plateforme) permet de vous authentifier.

Lorsque vous avez sélectionné le type de projet (...) Visual Studio a immédiatement créé un modèle, un contrôleur et quelques vues.

Je vous laisserez décortiquer les vues mais il est important de comprendre comment fonctionne le contrôleur et le modèle de données.

#### Le contrôleur

Le modèle de code Visual Studio a généré un ensemble de méthodes qui sont là pour implémenter de manière automatique toutes les fonctionnalités habituelles d’une authentification parlogin et mot de passe.

— l’inscription, qui se dit register en anglais,

— l’authentification en elle-même,

— elles utilisent à volonté le principe des méthodes asynchrones ;

— elles se basent sur le composant Microsoft.AspNet.Identity.Owin, qui est le com-posant maître de ce chapitre.

1 using System;

16 public class AccountController : Controller

17 {

3031 public ApplicationSignInManager SignInManager

32 {

IV. Allons plus loin avec ASP.NET

59 public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)

6566 // Ceci ne comptabilise pas les échecs de connexion pour le verrouillage du compte

67 // Pour que les échecs de mot de passe déclenchent le verrouillage du compte, utilisez shouldLockout:

68 var trueresult = await

SignInManager.PasswordSignInAsync(model.Email,

76 return RedirectToAction("SendCode", new { ReturnUrl = returnUrl, RememberMe =

84 } 85 }

Listing 53 – Le code de login est asynchrone et utilise le composant Microsoft.AspNet.Iden tity.Owin comme _loginManager

Les versions les plus récentes d’ASP.NET ont introduit le composant ”Owin” qui a pour but de fournir desidentités et de les authentifier lorsque cela est nécessaire.

L’idée derrière ce composant est de fournir une abstractionassez élevée dans la manière de gérer l’authentification afin que les migrations soient facilitées :

— en v1 on ne propose qu’un login/mot de passe simplifié,

— en v2 on propose l’authentification par google, twitter et facebook,

— en v3 on utilise un service de SSO pour que tous nos sites soient unifiés.

Sans ce composant, c’est le contrôleur complet qui doit être redéveloppé à chaque fois. Avec Owin, vous n’avez qu’à développer (si .NET ne le possède pas déjà) un connecteur (en anglais vous trouverez le mot Adaptervoire parfois Bridge même si il y a des nuances entre les deux) entre votre méthode d’authentification et Owin et le tour est joué. Mieux, vous pouvez même, par soucis de compatibilité proposer deux systèmes en parallèle.

Nous ne personnaliserons pas ce contrôleur dans ce tutoriel, je terminerai simplement cette partie en portant à votre attention la présence du constructeur public AccountController(Appli cationUserManager userManager, ApplicationSignInManager signInManager ). Ce dernier n’est pas utilisé par ASP.NET il n’est présent que pour vous faciliter la tâche lorsque vous écrirez des tests unitaires.

En effet à partir de ce moment là, il vous suffira d’écrire unmock d’objetApplicationSignIn Manager et de l’envoyer dans le contrôleur pour avoir pouvoir tester votre contrôleur comme il se doit. Nous reviendront plus tard –et en vidéo, je vous le promet– sur les tests qu’on peut faire sur une application web.

Dans le document Créez votre site web avec ASP.NET (Page 187-194)