In a common MVC designed applicaton, is it a bad idea to make the service layer dependant on a user session? Let's say there is a service method that fetches a few objects from a database, and you wish to return different results depending on who initializes the call - for example an administrator might get 10 rows of objects, while a normal user might only get 7 rows because the last 3 were "administrator-only" objects. A few ways to solve this would be:
- Introduce a new method parameter where you include the calling user. Dependancy-less but cumbersome to have to throw in user parameters in many methods.
- Make different methods for different user roles (with multiple results). Also dependancy-less but lots of methods which does basicly the same thing, which increases the risk of code duplication.
- Let the method read from a ThreadLocal variable in a static context storing the current user session. This variable is set before each request.
Lately, i've started using the last method more and more since it provides a clean interface and feels very practical to work with. A Filter makes sure that the current thread always has a user set. Is this bad design? I believe that some could see this as a dependancy from the service layer to the web layer, though I personally think that they are pretty uncoupled. The biggest consequence is that a methods behaviour will be different depending on the state of another class, which could be both a bad and a good thing.
What are your thoughts on this? If it's a bad solution, what would be a stronger one?