ASP.NET MVC: Utiliser un compte existant ou créer un nouveau contrôleur Utilisateur?

Question

Je crée une nouvelle application ASP.NET MVC. Jusqu'à présent, j'ai utilisé le contrôleur de compte pour les actions liées au compte d'un utilisateur - Connexion/Déconnexion, Activation (comme Enregistrer, mais j'utilise Enregistrer pour d'autres actions dans le site, je l'ai renommé), Ajouter/Mettre à jour . Jusqu'à maintenant, cependant, je me suis concentré sur les vues des utilisateurs administratifs. Je suis au point où je vais commencer à créer les différentes vues que les utilisateurs non administratifs verront. Ceux-ci sont plutôt limités par rapport à l'interface administrative. Mon souhait est de créer un nouvel ensemble de vues et un contrôleur associé dans la "famille" de l'utilisateur au lieu d'utiliser les vues de compte/contrôleur. Est-ce une bonne idée ou devrais-je rester avec le contrôleur de compte? Mon sentiment est que puisque c'est pour les utilisateurs ordinaires, il devrait être un contrôleur séparé puisque le compte s'appliquerait aux utilisateurs ordinaires et administratifs.

EDIT: Après avoir lu les deux premières réponses, ma question refactorisé est:

Considérez-vous que le contrôleur de compte à des actions administratives liées au compte de l'utilisateur ou pour toutes les actions sur le compte de l'utilisateur? Feriez-vous la distinction entre les vues/données associées à l'appartenance/au rôle et les vues/données liées à l'application dans la mesure où vous créez un nouveau contrôleur?

connexes, mais ne répond pas directement à ma question: ASP.NET MVC Account Controller usage guidelines?

Answer 1

Je ne pense pas qu'il y ait un droit ou une mauvaise réponse ici, donc je vais vous donner mon avis. Techniquement, l'une ou l'autre solution (extension du contrôleur de compte ou création d'un nouveau contrôleur) fonctionnera correctement.

Donc, je pense que c'est plus une question de savoir comment les utilisateurs perçoivent la fonctionnalité. Je pense que c'est une bonne idée de suivre la convention que l'URI dicte le contrôleur (ou vice versa, si vous préférez).

Si, par exemple, vous souhaitez avoir les actions "administratives" sur un chemin séparé, cela doit être un contrôleur distinct. Vous pouvez le faire, par exemple, si vous utilisez un module IIS pour l'authentification ou si cela facilite l'analyse de votre journal. D'autre part, il se peut que les utilisateurs perçoivent les fonctions de compte et les fonctions administratives comme faisant partie de la même famille d'actions, sauf que certains utilisateurs ont des fonctionnalités supplémentaires. Si oui, alors cela suggère que cela devrait être sur le même chemin dans l'URI et, par conséquent, une partie du même contrôleur. En résumé, je pense que c'est une question que vous devriez poser à votre représentant d'utilisateur au lieu des gens sur ce site. :)

Mise à jour: En ce qui concerne votre question mise à jour, je dirais qu'il est assez naturel de mettre une action pour changer le mot de passe d'un utilisateur sur le contrôleur de compte, et que l'action pourrait être invoquée par l'utilisateur elle-même, non seulement un administrateur. Donc, je ne présume pas que le contrôleur de compte est strictement pour des tâches administratives. D'un autre côté, votre exemple de la collecte de fonds est bien en dehors de la portée des choses liées à l'adhésion, donc il n'est pas clair qu'il appartienne à Account, soit. Je suis toujours penché vers, "demandez à votre représentant des utilisateurs."

Answer 2

Dans ASP.NET MVC, vous créez généralement des contrôles basés sur des types de données plutôt que sur des types d'accès. Par exemple:

Au lieu de 2 /Controllers/UsersControl.cs et/Controllers/Admin/UsersControls.Il est plus facile d'utiliser un contrôleur commun pour les administrateurs et les utilisateurs réguliers - /Controllers/UsersController.cs (en définissant différents attributs et vues [Authorize]).

Je conserverais AccountController.cs existant pour l'encapsulation des fonctionnalités liées au compte. Et juste ajouter de nouveaux UsersController.cs pour le reste des fonctionnalités liées aux utilisateurs (qui pourraient avoir des méthodes comme OnlineUsers etc.)