title: Is it bad design to make your business(service) layer dependant on a user session?
body: <p>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:</p>
  
  <ul>
  <li>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.</li>
  <li>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.</li>
  <li>Let the method read from a ThreadLocal variable in a static context storing the current user session. This variable is set before each request.</li>
  </ul>
  
  <p>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.</p>
  
  <p>What are your thoughts on this? If it's a bad solution, what would be a stronger one?</p>