POCO + Entity Framework avec le modèle référentiel - autorisation de manipulation

Question

J'ai une application qui se compose de 3 couches:
UI: à mettre en œuvre dans ASP.NET MVC
affaires: Peut contenir la logique métier et l'accès aux ressources contrôle
Référentiel (DAL): implémenté avec les objets POCO et EF, en utilisant le modèle de référentiel. Mes objets POCO sont partagés avec les couches supérieures.

J'ai des questions sur les informations/méthodes que les POCO devraient avoir? i.e: si j'ai une table User qui contient un nom d'utilisateur et un mot de passe pour un utilisateur, que devrait avoir mon POCO? Comment devrais-je valider le mot de passe? Mes POCO devraient-ils avoir une méthode qui demande la validation du référentiel?

De même, comment devrais-je contrôler l'accès à mes ressources? Mes référentiels devraient-ils contrôler qui peut et ne peut pas accéder à une ressource? Cela permet toujours à mes POCO d'exposer des informations avec des propriétés de navigation. Dois-je vérifier dans la proposition POCO si l'utilisateur actuel peut les utiliser aussi?

Merci d'avance.

Answer 1

J'ai un projet similaire et je peux vous donner quelques détails sur la façon dont j'ai effectué des opérations similaires. Je suppose que votre solution entière est basée sur .Net. Les objets POCO (Plain Old CLR Objects) ne sont que des objets sans logique métier. Ainsi, les validations de mot de passe ne doivent pas être directement dans cette classe mais dans votre couche de gestion. Par exemple, l'interface utilisateur appelle une action du contrôleur pour soumettre les données au Business Layer (BL), le BL effectue la validation du mot de passe utilisateur en appelant le référentiel pour obtenir le mot de passe actuellement stocké/chiffré, BL compare les mots de passe et renvoie un résultat à votre interface utilisateur ou prendre une autre action. Bien sûr, toutes les données doivent également être validées pour éviter des attaques telles que l'injection SQL ou les attaques de type "Cross Site Scripting".

Votre POCO peut avoir des propriétés Uid/Pwd. Vous devriez contourner cet objet POCO entre vos couches d'application. Ainsi, l'interface utilisateur MVC serait liée à votre objet utilisateur et, une fois soumise, le contrôleur appellerait une méthode dans votre BL et exécuterait les règles métier (le mot de passe est valide) sur cet objet utilisateur. Pour les passer entre les couches réelles, vous devez extraire les POCO de la couche DAL principale et les placer dans un assemblage séparé. Ces objets sont communément appelés objets de domaine et vous pouvez google Domain Driven développement pour obtenir plus d'informations sur cette méthodologie.

La sécurité peut être implémentée de différentes manières au sein d'une application, tout dépend de la profondeur des éléments que vous souhaitez couvrir. Le plus fondamental dans MVC est d'utiliser l'attribut Authorize sur vos classes de contrôleurs (google: Sécuriser les actions de votre contrôleur).Lorsque votre utilisateur est authentifié, ils peuvent être assignés un certain type de rôles d'application et vous pouvez vérifier si l'utilisateur a un de ces rôles en utilisant le format suivant:

[Authorize(Roles = "ModifyUserRoles")] 
     public ActionResult About() 
     { 
} 

Answer 2

Si votre contexte retourne l'objet utilisateur, la sélection serait « valider » le mot de passe:

public User GetUser(string login, string password) 
{ 
//...code to set up context var... 
var user = (from o in context.Users.OfType<User>() where o.UserID == login && o.Password == password) select o).FirstOrDefault(); 
//...maybe more code... 
} 

Il devrait être à votre couche métier comment chiffrer le mot de passe et comment gérer un échec de connexion (méthode retourne null).

Personnellement, je ne pense pas que toute logique métier devrait être dans votre DAL. Déterminer qui a accès à la fonction la mieux exécutée par la couche de gestion, mais vous pouvez désactiver le chargement paresseux et inclure uniquement les propriétés de navigation basées sur l'utilisateur OU vous pouvez effectuer une requête supplémentaire pour ces propriétés lorsqu'elles sont nécessaires. La quantité et le type de données renvoyées (pour des raisons de performance) guideraient cette décision.

Answer 3

Je pense qu'il est pas toujours nécessaire de passer votre POCO objet (objet domaine) à travers des couches, par exemple dans votre situation, la couche View n'a besoin que d'un simple modèle de vue avec juste les propriétés nom d'utilisateur et mot de passe et le transmet à BL, c'est votre BL qui recevra l'objet domaine utilisateur via référentiel et valider le mot de passe par rapport à ce qu'il a reçu de la couche View.