What is the best approach if you have to implement a minimal change on several places of your application?

Question

Hi SOlers,

some time ago we implemented impersonation into our application (a DMS system). We did this because the users should not have access to the physical files of the document pages.

So the user logs into our application, gets impersonated to a special user so he can access the files he needs from within our application.

When this impersonation was planned we didn't think that it would be a great thing: The user impersonates one time and everything is fine. We implemented the code into the existing methods where it was needed (just sth. like Impersonation=true or Impersonation=false).

This was wrong: Impersonation had to set off and on on several places (for example, when the user wants to send a document as an email you have to set impersonation off to use the user's mail profile) so whenever we add a new functionality we have to test with and without impersonation.

Because I have additional functionality to implement I would like to extinct this behaviour to get a clean approach. But I don't really have an idea what could be best approach.

First thing that comes into my mind would be the state pattern, but this would result in an impersonated class and a not-impersonated class for all classes where impersonation takes effect. This would increase the number of classes. Other thing would be method pointers: When using impersonation call impersonated version of function, else call not-impersonated version of function. This would lead to more methods. Better than state pattern approach? I don't think so.

So, what would be your approach to get a clean solution? (I already thought about using threads but this seems to be very complicated)

Hope you can help me.

Regards,

inno

Answer 1

Sounds like a crosscutting aspect - maybe aspect oriented programming?

Answer 2

Well one option would be to define what the default behavior should be such as impersonation on for the user. This default behavior would happen at time of login to the system. When the user performs other behaviors in the system such as sending a document as email this could be encapsulated in a service where the service takes the user as an argument and then uses the impersonation necessary for that feature. To take your example:

var emailService = new emailService();

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