Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Architecture issue...common database access interface

 
Darrin Smith
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a situation that is probably very common and I am wondering how others architect it.

What I want to do is read from a database after a user logs on and have the data that gets retrieved stored off in a session bean so it can be made available to other pages that the user will see. So, each user will have their own set of data stored in their own session bean.

The technology involved is this: JSF (via Java Studio Creator) on the front end, with the Spring JDBC framework providing the database access.

In this project, every user will need to read from the database (common to all users that logon). Once they are authenticated, the database will be read to get a list of items to present on another web page (this web page will be forwarded to after the read completes).

My question is, what should be used to house the code for the common interface between the GUI and the Spring database access code?

Does it make sense to:

1) Create a Managed Application Bean that will act as the interface by adding a method like this:

List getMyData(String username, String userRole)

That way, there will be just one "Bean" that will act as a worker interface since every user will need to go through a common place to get to the Spring access code.

My thought was to verify that the user loggon on and then grab the application bean to call its getMyData method to return a List that I can store off in the user's SessionBean1 for later access (it will get placed into a Listbox on another page).

or

2) Create a singleton that will house the getMyData method and add that singleton to the Managed Application Bean, and then retrieve that bean and use it to access the singleton, to get to the method when needed.

3) Something else?

Note that no data will be stored in the Managed Application Bean (which...typically is what you would do with one) so that is why I was thinking that this may not be the way to do it, but having one object (a singleton) that would be used as a common gateway to the Spring code would be nice instead of instantiating a new object each time it is needed, and a Managed Application Bean would give me that as well as the option mentioned in number two.

Thoughts?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic