Service layer question

[bryanross]

Hi,

I'm currently converting an application that uses SLSB and Entity Beans into an app that uses Spring and Hibernate for all the standard reasons. I'm starting to design the services layer that the Struts actions will use and have a question about the separation of the services.

My action needs to get data to populate a few lists such as a list of people and a list of teams, etc to display to the user. The user will then fill in the fields, select items from the list and submit the form.

I will probably have separate service objects for the people and the teams as there will be some logic in both.

Is it a good approach to have the action contain multiple service objects or should it use a single service object and that service object contain all the methods necessary to fulfill the needs of the action? That would mean that the service object would make calls to other service objects.

Thanks for the help...

Bryan

[Rod Johnson]

Bryan

It's a matter of taste. I don't think there's necessarily any "right" or "wrong" answer. (Actually, as usual, there are probably multiple right answers, and even more wrong answers...)

Personally, I would probably let the controllers access different service layer objects, injecting all of them, unless it needs to access so many that you clearly need a facade. To provide a facade in the case where there are only 2 or 3 different service layer objects required smacks of code duplication: if the facade doesn't add any value, it's just more code to write and maintain.

Rgds
Rod

[bryanross]

Thanks Rod.

This is the approach I have always taken with Session Beans, but was curious about how others approached this using Spring.

I was also interested in how this impacted transaction and hibernate session management as each call down into the services layer would require a separate transaction. This normally isn't a problem as most of the calls into the services layer in my scenario would be read only.

Thanks again

Bryan