In the StudentServiceBean, i have injected EntityManager, so i directly do JPA operation in the methods written in this session bean.

No my question is can i use any design pattern in this flow, can i go for a separate DAO layer,
as i am using EJB 3.0 i don't have to use ServiceLocator pattern, but than any other pattern can i use to seperate Bussiness logic with the JPA call,

One more thing,
In JSF managed Bean i have properties and its getter setter methods which are mapped to the JSP componenets in EL like this
value={stMgBean.studentList}

but in the same managed bean i have also have method which will be invocked by action command call from JSF,
should those method be written in the seperate Managed bean ?

Please suggest a Design pattern which can be used for projects which have JSF 2.0, EJB 3.0 and JPA

Don't use DAOs if you don't have several different persistence providers. This will overcomplicate the architecture.
–
Adrian MitevMar 28 '12 at 7:18

OK, but does my set of class flow is sufficient for a big project, or should i split up managed bean into two for action command methods ans separate class for getter and setter mapped properties, what should be the class hierarchy in Bussiness layer where i have used EJB's, waiting for the reply
–
Rahul ShivsharanMar 29 '12 at 5:32

You should have 2 type of managed beans - controllers (execute ui logic and call business layer) and entities (jpa @Entities) that just transport the data without any logic inside. There's no need of hierarchies in the business layer -if you have something to reuse move it in a separate component and use it in multiple places
–
Adrian MitevMar 30 '12 at 4:44

1 Answer
1

Put all the data which are going to be shared between the java side and the view into specific managed beans called "Models". Now you can manage the scope of the data independently from the scope of the rest of managed beans.

Use the command pattern which delegates all the actions which will modified the model to the commands. The commands may invoke the EJB layer, or just update the models without going to the next layer.

Keep in the managed beans just the logic that you need to initialise the JSF components in the views or manage their behaviour, a reference to the model, and a reference to a delegator which will provide the command to run.