Seam and EJBs in practice; advice needed

[chris.simons]

All,

We've been developing an application in Seam for some time (1-2 years).

Thus far, we've grouped our business logic, navigation methods, entity queries (collections of objects returned via EJB-QL) into a single, stateful session bean per application module.

I'm seeing that our session beans are awfully long, mismanaged, and hard to follow.

I have read in the past that it is best to store entity queries in stateless session beans.  And I've wondered what the pros and cons of doing so are and whether we should take this approach.

Thus, I'm considering separating the single, stateful session bean into two beans:
1) a stateful session bean Manager, one that pertains to how the application interacts with the user and view layer; this bean would store conversational objects, perform page submits, and more.

2) a stateless session bean Helper, which would store commonly accessed entity queries and collections of objects; in this Helper class, entity queries would always expect parameters and not rely on what's available in the conversation (like we have been doing thus far)

In practice, how do you all separate these concerns and would you recommend the above approach or something better?

I appreciate your time.  Thanks.

[asookazian]

Chris Simons wrote on Jul 08, 2009 17:25:



Thus far, we've grouped our business logic, navigation methods, entity queries (collections of objects returned via EJB-QL) into a single, stateful session bean per application module.

Typically, you use one SFSB (or conversation-scoped JavaBean) as a backing bean per JSF/facelet.

I'm seeing that our session beans are awfully long, mismanaged, and hard to follow.

This is known as the bloated session bean anti-pattern and it happens to the best of us during strict deadlines.  You will need to refactor your component into possibly multiple re-usable components with the methods grouped logically.

http://books.google.com/books?id=g_F-z16b_o4C&pg=PA575&lpg=PA575&dq=bloated+session+antipattern

I have read in the past that it is best to store entity queries in stateless session beans.  And I've wondered what the pros and cons of doing so are and whether we should take this approach.

I am doing this with my StoredProcedureDAO SLSB.  If it's a service object that does not need to maintain state, you don't need to use a SFSB.  If you abstract it out of your SFSB backing bean, it's easier to unit test and more re-usable.

Thus, I'm considering separating the single, stateful session bean into two beans:
1) a stateful session bean Manager, one that pertains to how the application interacts with the user and view layer; this bean would store conversational objects, perform page submits, and more.

2) a stateless session bean Helper, which would store commonly accessed entity queries and collections of objects; in this Helper class, entity queries would always expect parameters and not rely on what's available in the conversation (like we have been doing thus far)

so basically a backing bean to handle the action methods from JSF pages and conversation modeling, etc. and a service object.

Rod Johnson (in one of his very popular Wrox books - I believe it's something like J2EE developement without EJB) recommends using a DAO layer if it is required.  If you have a lot of business logic and persistence logic in a SFSB, then it makes sense to abstract out the persistence logic into a DAO.  Otherwise, for a small simple CRUD app, it's not necessary.  I usually follow this advice.

In practice, how do you all separate these concerns and would you recommend the above approach or something better?

Everybody has their own different strategy/patterns/design.  And it depends on the project.  Your scenario and question is really a patterns question and is not specific to Seam (i.e. the same question applies for a Struts/EJB2 project as well as Spring/Hibernate).

HTH.

[chris.simons]

John - Thanks for the very helpful response; you made me realize exactly what we have been doing and based on your recommendations, I do think a separation is needed.

The reasons for doing so:
1) the application is very large; any given application module consists of dozens of JSF pages and supporting methods that are, right now, in a single stateful session bean

2) we have about two dozen of these application modules and more to come

I might have to check out this pattern/design book; thanks again.