Je développe une application de type CMS utilisant MVC 3 (RC2) et je suis à la croisée des chemins à ce stade. Je suis incapable de me convaincre si l'approche que je propose est appropriée ou non. Je suppose que c'est parce que je suis conscient que j'essaie de couper quelques coins qui me coûteront lourdement plus tard sur toute la ligne.Logique d'application (endroit approprié pour l'authentification/l'autorisation)
Je vais aller droit vers le bas pour décrire mon problème:
1) J'ai une ressource (permet de l'appeler A) qui doit être éditables.
2) J'ai un système d'autorisation personnalisé mis en œuvre qui a 2 (de plusieurs) autorisations:
- peut éditer ses propres ressources
- Can Modifier autres ressources
3) Créateur de ressources A est libre de l'éditer s'il a l'autorisation 'Can Edit Own Resource'.
4) Un utilisateur distinct ne pouvez modifier A si elles ont la permission « Can Modifier autres ressources »
Maintenant que l'exigence est décrite, laissez-moi vous dire mon approche jusqu'à présent:
1) I un contrôleur appelé 'ResourceController'
2) J'ai une action appelée 'Edit'
3) L'action a un attribut sur elle: [CustomerAuthorize (Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true) ]
4) J'ai une classe de service qui s'occupe de la validation de domaine.
Ainsi, un utilisateur appelle la méthode d'action s'il dispose de l'autorisation 'Can Edit Own Resource' ou 'Can Edit Other Resource'. Comment puis-je décider (et où prendre cette décision) si l'utilisateur a la bonne autorisation ou non (selon qu'il possède ou non la ressource?) Devrait-il être dans l'action du contrôleur, dans la classe de service de ressources , dans une classe de service distincte?
En attendant d'entendre différents points de vue ...
Mais n'est-ce pas la duplication de la logique? Avoir les mêmes contrôles répétés plusieurs fois? Mais je comprends votre inquiétude. Je me demande si je pourrais voir quelques projets OSS pour apprendre le modèle. – kidoman
@ KiD0M4N: Dans certains cas, il est beaucoup plus facile de répéter une certaine logique (y compris des considérations de maintenance à long terme) que de ne pas le répéter. C'est-à-dire que, parfois, des contraintes technologiques ou des décisions de conception existantes rendent déraisonnablement difficile la poursuite pure et simple de «ne pas répéter». –