Home/ Questions/Q 8281531
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T10:03:59+00:00

I use JSF, Hibernate and CDI with Weld. My application is divided in: View

  • 0

I use JSF, Hibernate and CDI with Weld. My application is divided in: View (xhtml), Control (Request/Session/View scoped Beans), Model (Entities) and Business (BO’s marked as Application scoped beans).

I try to keep Model and Business layers decoupled from View and Control as much as possible, meaning that if want to change all of the xhtmls + control beans, it’s possible without affecting Business Layer and Entities.

My problem is: There are a lot of methods in the Business Layer that need to know who is the logged user (or at least his Profile), because that will affect the results that are going to be returned back to the control layer.

E.g.: When requesting a list of Users to edit, an Administrator would receive a list with all registered users, and a Manager would receive a list with only the users that are “below” his profile.

I don’t want to inject my Session Bean (containing the logged user) into my Business Layer, because that would cause coupling (meaning that I wouldn’t be able to just change my Control/View layer at any time).

Nowadays I do this by passing the logged user as a parameter of my BO’s methods, but to me that “feels” wrong. I keep thinking that the Control layer can just pass whoever it wants as the logged user, and my Business layer would never know about it.

My final questions are:

  1. Is there anything wrong with the way I’m doing it? Or am I over thinking too much?
  2. Is there a better way to do it?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think it’s fine to put the user identity in the session scope, from where it can be picked up by beans in the domain layer. If your domain layer needs to know about user identity, then it’s a domain concept, and it’s okay for there to be an object for it there.

    However, you are right be concerned about leaking abstractions from the presentation layer. I would suggest that you define an interface for the user identity in the domain layer, with code in the domain layer being written in terms of that interface, and then inject an implementation of it from the presentation layer. Because the interface is defined in the domain layer, it can be written in terms of domain concepts, preventing leakage of presentation concepts into it.

    If you wanted to change your presentation layer, you would need to write a new implementation of the interface, but that shouldn’t be a problem.

    There is another approach you could take, which would be to use the Java Authentication and Authorization Service to bind the user identity to the thread of execution as it passes into the domain layer. Objects in that layer can then use standard JAAS constructs to access it. If your container supports JACC, then it might already be making user identities available through JAAS; i’m not really sure.

    • 0