2009-08-26 4 views
0

il y a quelque temps nous avons implémenté l'emprunt d'identité dans notre application (un système DMS). Nous l'avons fait parce que les utilisateurs ne devraient pas avoir accès aux fichiers physiques des pages du document. Donc, l'utilisateur se connecte à notre application, se fait passer pour un utilisateur spécial afin qu'il puisse accéder aux fichiers dont il a besoin depuis notre application.Quelle est la meilleure approche si vous devez implémenter un changement minimal sur plusieurs endroits de votre application?

Lorsque cette usurpation d'identité a été planifiée, nous n'avons pas pensé que ce serait une bonne chose: l'utilisateur usurpe l'identité une fois et tout va bien. Nous avons implémenté le code dans les méthodes existantes où il était nécessaire (juste sth. Comme Impersonation = true ou Impersonation = false). Cela a été faux: l'emprunt d'identité a dû se déclencher à plusieurs reprises (par exemple, lorsque l'utilisateur souhaite envoyer un document en tant qu'e-mail, vous devez désactiver l'emprunt d'identité pour utiliser le profil de messagerie de l'utilisateur). une nouvelle fonctionnalité que nous devons tester avec et sans usurpation d'identité.

Parce que j'ai des fonctionnalités supplémentaires à implémenter je voudrais éteindre ce comportement pour obtenir une approche propre. Mais je n'ai pas vraiment d'idée de ce qui pourrait être la meilleure approche.

La première chose qui me vient à l'esprit est le modèle d'état, mais il en résulterait une classe usurpée et une classe non-usurpée pour toutes les classes où l'usurpation d'identité prend effet. Cela augmenterait le nombre de classes. Autre chose serait pointeurs de méthode: Lors de l'utilisation de l'emprunt d'identité appelez la version impersonated de la fonction, sinon appelez la version non-impersonated de la fonction. Cela conduirait à plus de méthodes. Mieux que l'approche du modèle d'état? Je ne pense pas. Alors, quelle serait votre approche pour obtenir une solution propre? (J'ai déjà pensé utiliser des threads mais cela semble être très compliqué)

J'espère que vous pouvez m'aider.

Cordialement,

inno

Répondre

0

Sons comme un aspect transversal - peut-être la programmation orientée aspect?

0

Bien une option serait de définir ce que le comportement par défaut devrait être tel que l'emprunt d'identité pour l'utilisateur. Ce comportement par défaut se produirait au moment de la connexion au système. Lorsque l'utilisateur exécute d'autres comportements dans le système, tels que l'envoi d'un document en tant qu'e-mail, il peut être encapsulé dans un service où le service prend l'utilisateur comme argument et utilise ensuite l'emprunt d'identité nécessaire pour cette fonctionnalité. Pour prendre votre exemple:

var emailService = new emailService(); 

//inside the service call it would apply the impersonation necessary for the operation 
emailService.send(user, new Attachment(documentToSendViaEmail)); 
Questions connexes