I’ve been developing my first Java EE app, which has a number of JPA entity classes, each of which have a corresponding EJB class for dealing with the business logic. What I’ve done is changed one of those beans from Stateless to SessionScoped, so I can use it to allow a user to work their way through a series of form fields, all of which are rendered on a JSF form.
However, I’m starting to think this is clearly wrong, as I’m doing things like implementing methods such as “submitStep1” and “goBackToStep2” in my EJB. These methods set indicators which are used by render elements of various tags on the JSF page, so they are clearly “presentation logic”.
My question is, how should I re-structure my code? I’m thinking that I should just have one SessionScoped (or should that be stateful?) bean, which deals with the presentation logic of my JSF page, and is able to use all the other ejbs (and by extension my JPA classes). This bean would be in the presentation-tier level of my app, meaning my business logic tier wouldn’t need any Session Scoped Session Beans.
Now this all makes sense to me, and is what I am probably going to do. However the reason for my question is that on my JSF xhtml pages I use JSF EL tags a lot to refer to EJB content. Are there any JPA-related pitfalls I need to watch out for when writing presentation tier classes?
I know my question is pretty vague, and not really related to a specific example. And although I’ve found quite a lot out about Stateful v Stateless beans on this and other sites I just want to know my intended structure is the best one.
Why don’t you use backing beans for presentation purpose, as they are intended for it, and you can easyly configure its scope, and leave the EJBs to business tier?
When using entities directly on the presentation tier, you should be aware of the transaction scope, specially regarding lazy relationships. That is, normally it is used one transaction per request, what will mean that amongst different requests, the entities will become detached, so you will need to reatach them to be able to load lazy relationships. You could use a filter that does it automatically each request or handle it by hand. You could also keep the same transaction during different requests but a long transaction is normally not a good idea, specially if there are updates/creations in the DB during this transacion.