2009-03-11 7 views

Répondre

3

Je vote pour le mettre là où c'est logique. La plupart de mes informations d'autorisation sont gérées via les actions du contrôleur de décoration (ou même de certains contrôleurs) avec AuthorizeAttribute - ou un attribut dérivé de celui-ci. Dans certains cas - comme mes menus - j'ai eu recours à la vérification d'autorisation dans le code de la vue, plutôt que de la calculer dans chaque contrôleur et de faire passer des drapeaux dans ViewData. Il y a quelques cas où certains aspects du modèle ne sont disponibles que pour des rôles particuliers et dans ces cas, j'ai eu recours à l'extension du modèle avec des méthodes qui peuvent prendre l'utilisateur et les rôles actuels et y faire un contrôle.

0

Si vous devez choisir entre M, V ou c, le C est l'emplacement correct. Mais, je recommande une architecture où votre application est contenue dans les bibliothèques et l'interface utilisateur est juste un mince placage. Vous finissez par appeler la pile du contrôleur, mais le code n'est pas dans le contrôleur.

Dans MVC, le modèle est juste un modèle, ou un "objet de données stupide", si vous voulez. Il est conçu pour maintenir l'état, et ne devrait pas dicter le comportement. La vue est pour l'utilisateur d'interagir avec et est également "stupide"; la vue gère l'interface utilisateur. Le contrôleur est où le comportement se trouve, ou est le point d'entrée dans le comportement dans le cas où la logique de l'application est dans les bibliothèques. Avoir du sens?

+3

Votre définition de MVC est incorrecte. Le M dans MVC est la partie la plus importante, ce n'est pas un objet de données stupide. Le comportement devrait être en M, c'est la logique de votre entreprise. Je ne sais pas si l'autorisation fait partie de la logique métier. –

0

Modèle.

Le contrôleur est juste pour commuter de différentes manières. La vue est juste pour ... regarder.

Vous devez donc créer tous les codes d'autorisation dans le calque Modèle. Idéalement, tout ira bien. Si ce n'est pas le cas, le contrôleur amènera l'utilisateur dans la boîte de connexion appropriée.

1

Je pense que l'autorisation est une préoccupation transversale. Devrait être dans un endroit - un aspect qui peut être appliqué de manière déclarative là où c'est nécessaire.

1

Le contrôleur!

Votre vue doit uniquement gérer l'interface utilisateur et afficher Votre modèle doit représenter les données de votre système. Votre contrôleur doit gérer la logique du fonctionnement du système. L'autorisation d'un utilisateur consiste à prendre les informations d'identification fournies par la vue, à les vérifier par rapport à une sorte de liste d'autorisations dans le modèle, puis à effectuer une vérification.

Cela se fait dans le contrôleur: Obtenir des informations d'identification d'utilisateur de l'affichage si (à comparer avec la liste des utilisateurs dans le modèle retourne en jeu) autorisent les utilisateurs autre refuser l'accès

Questions connexes