-
1. Re: business slash service layer best practice
asookazian Sep 29, 2009 1:16 AM (in response to jspring)Use a DAO layer if you have a lot of business logic and persistence logic. Otherwise, if your app is mostly persistence (CRUD) operations, a DAO layer may be unnecessary/overkill.
You will need to inject the DAO class into your business component.
-
2. Re: business slash service layer best practice
jspring Sep 29, 2009 2:34 AM (in response to jspring)Thank you for your reply.
1) I am also coming from a Struts and Spring background where the action / business / DAO layers were all very well separated. I believe this is a good design principle, to promote high cohesion and low coupling. With that in mind, the DAO layer currently in place simply retrieves entity bean backed data (there is no create, update, or delete). I don't feel like the DAO classes are the appropriate place for business logic though. Perhaps I am wrong.
2) Is it possible to inject a container-managed persistence context into a plain java bean, or is it only possible to to do this with a stateful / stateless session bean?
-
3. Re: business slash service layer best practice
asookazian Sep 29, 2009 7:33 AM (in response to jspring)1) biz logic does not belong in DAO classes. use SFSB/SLSB or JavaBean components to house your biz logic.
2) use @In to inject a conversation-scoped SMPC into any JavaBean or SFSB/SLSB which has @Name (declares class as a Seam component). You can only use @PersistenceContext to inject a tx-scoped or component-scoped PC.
more info: http://seamframework.org/Documentation/WhenDoIUseInVsPersistenceContextToInjectAnEntityManager
-
4. Re: business slash service layer best practice
jspring Sep 29, 2009 11:21 PM (in response to jspring)Thanks, that solved my problem. I have a stateless session bean referencing a persistence context and being injected into another stateless session bean (service class). In trying to inject the service class into the action session bean, I was referencing the implementation class type rather than the local interface type for the bean. After changing this, I found that both @In and @EJB annotations worked, but I will be sticking with @In. Thanks again.