why shouldn't entity bean be managed by JSF fr

Question

I read some post hear (specially BalusC post) and googled for the reason (not deep) but i couldn't find why shouldn't use entity bean as a managed bean. what's the reason? (I'm learning from "Pro JSF and HTML5" and in this book, entity bean is used as a managed bean.)

Answer 1

Separation of concerns.

Normally, enterprise applications are developed and deployed as EARs instead of WARs. A typical EAR project consists of an EJB subproject as "back-end" and a WAR subproject as "front-end". The EJB subproject contains all JPA entities and EJB services. The WAR subproject contains all JSF managed beans and views (and what not closely related to JSF such as converters, validators, phase listeners, etc).

A good EJB subproject may not have any dependency on JSF. This makes it reusable for different front-ends, such as Spring MVC, JAX-RS, Struts2, plain JSP/Servlet or even a desktop oriented Swing application. This also means that no one of your JPA entities and EJB services should have any javax.faces.* import/dependency in the class. Having for example a FacesContext at hands inside a JPA entity or EJB service is alarming as that doesn't necessarily exist in other front-ends.

The "Pro JSF and HTML5" concentrates on simple WAR projects. Therein that's "okay" in order to show the possibilities and/or to keep the examples "simple", but that's actually misleading to starters once they grow into developing enterprise applications, the more so if the book doesn't cover the design concern in detail.

See also:

• JSF Service Layer
• Packaging EJB in JavaEE 6 WAR vs EAR - related answer from my colleague Arjan.