This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have just started looking at jboss seam to understand what benifits does it provide to the web application, which can be developed with Spring, JPA and jsf.
I did say Spring instead of Session beans because i am big fan of Spring.
My First observation was doesn't it make things more complicated by putting session beans and JSF action beans in one class. Also don't we loose the decoupling concept we learned in our basics.
I understand that i makes like simpler and there is less code to maintain now but i see a tradeoff which might or might not be worth the effort.
Also don't we loose the decoupling concept we learned in our basics.
When you use seam, seam is the component which decouples your view from the model. All communication between your view and model goes through seam and hence it is quite easy to replace either of them with a different technology seamlessly
Do not dwell in the past, do not dream of the future, concentrate the mind on the present moment.
In theory, you can "de-couple" everything into infinite number of layers -- it just a matter of how much de-coupling you actually NEED. If you really need to de-couple the JSF actions from EJB services, you can easily do that with Seam: Just make a POJO component that acts as JSF event handlers and make it invoke other service objects in the backend.
Hi , I also have such feeling that it may make different layer more couple.
e.g. ejb3 entity bean can be directly accessed in jsf . is it a good practice?
i.e. if anything in DB change will lead to change in ejb3 entity and presentation layer as well.
any comment ?