Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The service layer (the business model) should be designed around the main entity (the data model). E.g. <code>UserService</code> for <code>User</code>, <code>ProductService</code> for <code>Product</code>, <code>OrderService</code> for <code>Order</code>, etc. You should absolutely not have one huge service class or so. That's extreme tight coupling.</p> <p>As to the service layer API itself, Java EE 6 offers EJB 3.1 as service layer API. In the dark J2EE ages, long time ago when EJB 2.0 was terrible to develop with, Spring was more often been used as service layer API. Some still use it nowadays, but since Java EE 6 has incorporated all the nice lessons learnt from Spring, it has become <a href="https://blogs.oracle.com/arungupta/entry/why_java_ee_6_is" rel="noreferrer">superfluous</a>. Note that EJB (and JPA) is not available in barebones servletcontainers such as Tomcat. You'd need to install for example OpenEJB on top of it (or just upgrade to TomEE).</p> <p>Regardless of the service layer API choice, best would be to keep your JSF backing bean (action)listener methods <em>as slick as possible</em> by performing the business job entirely in the service layer. Note that the service layer should by itself <strong>not</strong> have any JSF dependencies. So any (in)direct imports of <code>javax.faces.*</code> in the service layer code indicates bad design. You should keep the particular code lines in the backing bean (it's usually code which adds a faces message depending on the service call result). This way the service layer is reuseable for other front ends, such as JAX-RS or even plain servlets.</p> <p>You should understand that the main advantage of the service layer in a Java EE application is the availability of container managed transactions. One service method call on a <code>@Stateless</code> EJB counts effectively as a single DB transaction. So if an exception occurs during one of any DAO operations using <code>@PersistenceContext EntityManager</code> which is invoked by the service method call, then a <em>complete</em> rollback will be triggered. This way you end up with a clean DB state instead of a dirty DB state because for example the first DB manipulation query succeeded, but the second not.</p> <h3>See also:</h3> <ul> <li><a href="https://stackoverflow.com/questions/8459903/creating-a-master-detail-user-interface-for-entities-which-bean-scope-to-choose/">Creating master-detail pages for entities, how to link them and which bean scope to choose</a></li> <li><a href="https://stackoverflow.com/questions/18369356/when-is-it-necessary-or-convenient-to-use-springjsf2-or-ejb3jsf2-or-all-of-the/">When is it necessary or convenient to use Spring or EJB3 or all of them together?</a></li> <li><a href="https://stackoverflow.com/questions/30639785/jsf-controller-service-and-dao">JSF Controller, Service and DAO</a></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload