4

À des fins pratiques, je suis sur le point de créer une nouvelle application ASP.NET MVC 3.0. Ma solution (Practice.sln) aura 4 couches:Fournisseur d'appartenances à partir de la couche de service

  • Pratice.Common (bibliothèque de classe pour mes ViewModels)
  • Pratice.Data (bibliothèque de classe pour EF)
  • Pratice.Service (bibliothèque de classe pour la logique métier)
  • Pratice.Web (asp.net mvc 3.0 projet)

Supposons que j'ai une vue appelé « Connexion » qui est fortement typé sur un LoginModel défini dans ma couche Practice.Common. Le LoginModel a 2 propriétés (nom d'utilisateur et mot de passe).

Dans mon contrôleur, lorsque l'utilisateur envoie le formulaire, j'appelle la méthode suivante:

[HttpPost] 
public ActionResult Login(LoginModel model) 
{ 
    if(_service.ValidateUser(model)) 
    return null; 
} 

Le ValidateUser() est une méthode définie dans la couche de ma Pratice.Service (dans mon fichier LoginService.cs) .

Je déléguant fondamentalement le processus de validation à ma couche de service ...


Ma question est la suivante:

Considérant que je voudrais essayer/utiliser les avantages du fournisseur d'appartenances et Considérant que la plupart (sinon la totalité) de ma logique se passe dans ma couche de service, comment déplacer Adhésion dans ma couche de service? (Si c'est même une bonne chose)

aussi ... Je comptais sur la création de mon propre fournisseur d'appartenances par opposition à l'intégré depuis que je ne suis pas en utilisant tous les générer des tableaux et sprocs ...

question Bonus :

Est-ce considéré comme la meilleure pratique d'avoir toutes les connexions et la gestion de compte qui se passe directement à partir de votre contrôleur et tout le reste de ma logique métier conservé dans ma couche Service? Je suis curieux dans le pour et le contre d'avoir des "parties" de la logique qui se passe directement à l'intérieur du contrôleur et d'autres "parties" qui se passent dans la couche de service.

Bien sûr, si quelqu'un a un lien ou un article qui explique cela, je serais reconnaissant!

Sincèrement

Répondre

3

Ok, après quelques essais et plus de lecture, j'ai réussi à répondre à mes propres questions. En ce qui concerne le déplacement du fournisseur d'appartenance vers ma couche de service (dans mon cas) cela n'a aucun sens puisque mon niveau de service dépendra désormais de System.Web.Security et je ne le veux pas.

En outre, j'ai rapidement réalisé que je confondais deux concepts. FormsAuthentication et adhésion. Bien qu'ils travaillent main dans la main, je n'ai pas besoin de toutes les méthodes fournies par les membres. Par conséquent, je n'ai pas besoin de créer un fournisseur d'appartenance personnalisé ni d'utiliser celui intégré.Tout ce que je dois faire est de continuer à créer mes méthodes dans mon Service Layer (comme une méthode Login()) et puis, créer manuellement un FormsAuthenticationTicket que je vais ajouter dans un cookie puis ajouter ce cookie à la collection de cookies (dans le contrôleur).

En note, j'ai également réalisé que c'est seulement une fois que vous avez ajouté le cookie à la collection de cookies que HttpContext.User.Identity.IsAuthenticated commence à retourner TRUE. En ce qui concerne ma question de bonus, sauf indication contraire, je conserverai le mécanisme de connexion (et de validation) dans la couche de service au lieu d'avoir une certaine logique dans le contrôleur et une certaine logique dans la couche de service.

+0

Vous dites que vous avez fait quelques lectures ... attention à préciser où? –

Questions connexes