I am going to redesign a moderate size application (not v big but larger then normal).
Now I have few Question in my mind.
I am using JSF as front-end, EJB3 Session Bean for Business Logic and last but not the least JPA as domain model.
1 - With JPA we have a domain classes. Now its better to use entity as manage-bean for JSF or manage bean should be saperate.
2 - Using DTO (Data Transfer Object) is good practice or not in JEE5.
3 - Simplicity or Complexity but with EntityManager I feel no need of DAO but I am used to with DAO pattern. So again as best practice I have to make 1 session bean as DAO and call it from all the session bean where I write business logic or forget about DAO session bean and call EntityManager from all session bean everywhere.
4 - For initializing EJB JNDI is 1 way other way is @EJB EJBCLASSNAME ejbclassobject; //this auto initialize and create object.
Initializing like above is standard or it is an extended support from some app server.
* In a plain JSF/EJB 3/JPA application, JPA entities or EJB session beans cannot be managed backing beans. However, if you are using JBoss Seam with JSF, you can use both JPA entities and EJB session beans directly in JSF. I have doe this and have gotten very good feedback from developers in terms of usability and productivity. However, even while using Seam, it is sometimes obvious that you still need a separate backing bean to handle some presentation tier logic that really is not a good idea to be in an EJB that's supposed to be agnostic of the view technology you are using. Seam doesn't stop you from doing that when it's needed.
* Using a DTO is not really necessary in Java EE 5. Not having it usually cuts down on a lot of redundant code.
* It is very true that the entity manager API makes the DAO layer obsolete in many cases. What I have found is that DAOs are a still a good idea to abstract JPQL code. This is especially true since you are designing a mid-sized application that might change it's persistence technology over time. EJB 3.0 session beans are very well-suited to a robust DAO layer since they are just POJOs, injectable, thread-safe, transactional and pooled.
* I recommend avoiding JNDI look-up as much as possible and just sticking with @EJB/@Resource (it is standard). The only place JNDI is really a good choice is for JSP. Everywhere else, injection many be used (including unit tests, utility classes, application clients and the like). If and when needed, you can utilize Spring for enhanced DI: http://www.ctjava.org/camp2008/sessionB.jsf?cid=1952 (or Seam DI features, Guice, etc).
Do let me know if you would like any of the above clarified.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1