My Question is not about how to use HTTP session or how values are being used in session. Question is more oriented about approach.

In my current application there are few values being stored in the Session and we require those values every now and than, here are few values we fetching from session

  1. Store
  2. Language
  3. Customer
  4. few others

I can fetch these values from session like

request.getSession().getAttribute( "name" )

I need those values not directly in my Controller, but in other layer (say Facade) so I have 2 options

  1. Pass each required values to Facade method by request.getSession().getAttribute( "name" ).
  2. Create a method in each Facade Class like.

Method in Facade

 private Object getSessionValue(final String key) {
    ServletRequestAttributes reqAttr = (ServletRequestAttributes) RequestContextHolder
            return reqAttr.getRequest().getAttribute(key);

Though both are working find in my case, but with one exception, I need to have this method on each Facade Class or need to fetch each object in Controller.

Is there any other way or approach which might be more clean or my current approach is fine


My personal approach would be not to use the session everywhere. I'd try to reduce its usage at the controller layer. In the controller I'd extract what I need for my business logic and the later will never know that there is a web session involved. This will make that logic portable to non-web applications, and will work with all its data in a type-safe manner that is free of boilerplate code.

If you want to avoid the boilerplate code of obtaining the request, then the session, and then the items from the session, your method approach is fine enough, and a common practice in my experience. If you are using it in Java, you can improve it a little by adding some generics:

 public static <T> T getSessionValue(final String key) {
    ServletRequestAttributes reqAttr = (ServletRequestAttributes) RequestContextHolder
        return (T) reqAttr.getRequest().getAttribute(key);

You can use it now like this:

Integer someSessionInt = SessionUtils.<Integer>getSessionValue("someSessionIntKey");

I am assuming the method is defined in a static SessionUtils class. If you define it in a base controller class, want to use this from inside of a controller, you should call it this way:

Integer someSessionInt = this.<Integer>getSessionValue("someSessionIntKey");

The this keyword can be substituted with super, but without it a compile error would occur due to the generics.

In addition to my suggestion above, there is another way of hiding the session usage and have a session-free and independent API/facade. By sticking to the programming-to-interfaces paradigm you can have interface implementations that use the session, but it is never shown by the interfaces you enforce in your facade/api. So, for instance you may have a general purpose authorization service, exposed trough interface, that shows you who is the currently logged user, if s/he is a guest and whether s/he has a particular permission. Your application then could use a concrete implementation of the service interface that gets the user from the session. When you use the service, the interface does not expose anything related to the session, so all usages remain session agnostic, and type safe.

| improve this answer | |
  • +1 for suggestion of generics. your point about code portability is good one. I will move this code to BaseCOntroller and will pass everything to the Facade.My assumption about making Facade method signature as clean as possible do not make much sense :) – Umesh Awasthi Nov 29 '13 at 10:25
  • I added a little update. I suppose you are familiar with the mentioned concepts so I did not dug too deep in them, but this can be a nice way to still have a clean facade – Ivaylo Slavov Nov 29 '13 at 10:36
  • i am aware about this, but have no other option but to save and fetch values from the session and each time I look at code in my facade with RequestContextHolder, I start doubting its usage so though of getting a more inputs :) – Umesh Awasthi Nov 29 '13 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.