web-dev-qa-db-fra.com

Découplage de l'identité ASP.NET MVC 5 pour permettre la mise en œuvre d'une application en couches

Je suis nouveau sur ASP.NET MVC et j'ai développé une application MVC 5 avec authentification utilisateur individuelle. J'ai fait un modèle en couches lors de mes applications comme la séparation de la couche Model, de la couche DAL, des Repos, etc. etc. mais maintenant dans MVC 5, je veux pouvoir utiliser la gestion et l'authentification des utilisateurs et des rôles qu'ils appellent Identity , puis j'ai toujours cette structure en couches pour mon application, car en ce moment, il semble que l'identité soit à peu près couplée au projet MVC lui-même avec les utilisateurs et les modèles de rôle là-bas et le contexte aussi.

Ce que j'ai fait dans mon application pour l'instant, c'est que j'ai toutes mes couches supposées être séparées comme mon DAL, UnitOfWork, Repos, d'autres modèles, etc. dans le projet MVC (dans des dossiers séparés!) Juste pour le faire fonctionner, pour maintenant. Et je sais que ce n'est tout simplement pas la bonne façon de procéder.

Alors, quelqu'un peut-il m'indiquer de bons exemples ou articles à ce sujet ou l'expliquer directement si c'est possible ou non et comment? Google ne m'a pas sympathisé à ce sujet. Merci!

c#asp.netasp.net-mvcasp.net-mvc-5asp.net-identity
43
Bairose

Voici un brouillon de ce que j'essaierais ... Je créerais ces couches:

  • Contoso.Core (bibliothèque de classes)
  • Contoso.Data (bibliothèque de classes)
  • Contoso.Service (bibliothèque de classes)
  • Contoso.Web.Framework (bibliothèque de classes)
  • Contoso.Web (ASP.NET MVC 5.0)

Contoso.Core:

Cette couche contient toutes mes entités/classes représentant mes TABLES de base de données.

Ainsi, par exemple, j'aurais:

  • Classe User.cs.
  • Classe Product.cs
  • Classe ProductDetail.cs
  • Etc..

Certaines personnes appellent ces entités/classes: les objets de domaine, d'autres l'appellent les classes POCO.

Soit ou, ces entités/classes sont définies dans la couche principale car elles peuvent (ou non) être utilisées parmi les autres couches.

Contoso.Data:

Cette couche est l'endroit où je définis ma classe ContosoDbContext.cs. C'est à l'intérieur de ce fichier que j'ai défini tous mes DbSet<>. Ainsi, par exemple, j'aurais ce qui suit dans mon ContosoDbContext.cs:

  • utilisateur DbSet public {get; ensemble; }
  • public DbSet Product {get; ensemble; }
  • public DbSet ProductDetail {get; ensemble; }

Inutile de dire que la couche Contoso.Data AURA UNE DÉPENDANCE sur la couche Contoso.Core. De plus, c'est à l'intérieur de cette couche Contoso.Data Que j'aurais mon référentiel générique et tout ce qui concerne "l'accès aux données".

Contoso.Service:

Cette couche serait l'endroit où je place toutes mes règles métier. Par exemple, je peux avoir une classe UserService.cs Qui pourrait avoir une méthode Login(). La méthode Login () recevrait un nom d'utilisateur/mot de passe et appellerait le référentiel pour rechercher l'utilisateur.

Parce que la couche Service a besoin du référentiel, J'AI UNE DÉPENDANCE sur la couche Contoso.Data ET parce que je vais jouer avec la classe User (qui se trouve à l'intérieur de la couche Contoso.Core), J'AI AUSSI UNE DÉPENDANCE sur la couche Contoso.Core.

Contoso.Web.Framework:

Cette couche aurait une dépendance sur Contoso.Core, Contoso.Data Et Contoso.Service. J'utiliserais cette couche Contoso.Web.Framework Pour configurer mon injection de dépendance.

Contoso.Web:

La couche finale, l'application MVC 5.0, dépendrait des couches Contoso.Web.Framework ET Contoso.Service ET Contoso.Core.

Les contrôleurs invoqueraient des méthodes vivant à l'intérieur des classes définies dans votre couche Contoso.Service (Par exemple la méthode Login ()).

La méthode Login () peut ou non, par exemple, renvoyer une classe User (nulle ou remplie) et parce qu'elle renvoie une classe User ET PARCE QUE nous sommes à l'intérieur d'un Controller, notre couche Contoso.Web A besoin d'une dépendance sur le Contoso.Service Et Contoso.Core.

Bien sûr, je n'ai pas détaillé tout ici ou chaque couche, mais c'est juste pour vous donner un exemple du type d'architecture que j'utiliserais.

Jusqu'à présent, je n'ai pas répondu à votre question, mais avec peu de connaissances sur MVC 5.0 et son nouveau mécanisme d'identité, je pense que la couche Contoso.Core Devrait avoir une dépendance sur Microsoft.AspNet.Identity.EntityFramework En plus de le Microsoft.AspNet.Identity.Core

De même, ma classe ContosoDbContext.cs Devrait implémenter l'interface IdentityDbContext qui se trouve appartenir à Microsoft.AspNet.Identity.EntityFramework.dll.

Cela signifie que ma couche Contoso.Data Dépendrait de Microsoft.AspNet.Identity.EntityFramework Et très probablement de Microsoft.AspNet.Identity.Core Aussi ...

Comme vous le dites, lorsque vous créez un nouveau projet MVC 5.0, tout cela existe et est défini dans la même application. Rien n'est ou n'a été découplé en couches. Ainsi, dans l'architecture ci-dessus, la classe ContosoDbcontext.cs Vit à l'intérieur de la couche Contoso.Data Et NON directement à l'intérieur de l'application ASP.NET MVC.

Étant donné que je n'ai pas essayé la nouvelle identité ASP.NET ni essayé de dissocier les choses, je ne saurais pas répondre honnêtement à votre question. Je suppose que vous devrez essayer de faire bouger les choses.

Si et quand vous le faites, n'hésitez pas à nous dire comment cela s'est passé et quelles sont les choses/problèmes que vous avez rencontrés.

En attendant, j'espère que cela vous a aidé à faire la lumière (ou pas).

Vince

33
Vlince