JSF-SPRING-HIBERNATE architecture- Backing bean related best practice - spring

Question

I am developing a web project and after much research I have decided to go ahead with JSF+Primefaces, Spring and Hibernate approach. While designing the architecture of my project I have finalized the following approach :
Actor --> JSF+PrimeFaces page --- > Backing Bean -- > Service Bean -- > Dao -- > Hibernate
Service Bean and DAO are spring beans with dependency injection.
My concern now is now with respect to backing bean:
I plan to use multiple backing beans for UI page depending upon the type of Page I need to render.
Now for example: For a new user registration page i have UserProfile.xhtml which uses UserBackingBean. UserBackingBean has UserServiceBean injected by spring. UserServiceBean has UserDao injected by Spring.
Now in UserBackingBean when the user enters the form data from UserProfile.xhtml I will have to populate the User.java domain(ORM) object.
a) What is the best practice for this ? Should I initilize the User.java in the constructor on UserBackingBean ? Is this the proper approach ? Please suggest if there is any other way out ?
b) Also please suggest on the above architecture I have decided upon for my project ? Is it the proper approach ?

Answer 1

The general rule I follow is that transaction boundaries are marked in the service beans therefore I don't like to modify hibernate POJO outside of a service because I don't know if there is a transaction already running. So from the backing bean I would call the service layer pass in the parameters that the service layer needs to build up the hibernate pojo and save it, update it, ... etc.
Another way to do this would be have your backing bean implement an interface defined by the service layer and then pass the backing bean to the service layer. For example.
public interface UserInfoRequest {
public String getName();
}
#Service
public class SomeSpringService {
#Transactional(.....)
public void registerNewUser(UserInfoRequest request)
{
}
}
public class SomeBackingBean implements UserInfoRequest {
private SomeService someSpringService;
public void someMethodBoundToSJF()
{
this.someSpringService.registerNewUser(this);
}
}
Regarding your last question I am not a fan of JSF, I think JSF is fundamentally flawed because it is a server component based framework. So my argument against JSF is a generic argument against server side component based frameworks.
The primary flaw with server side component based frameworks is that you don't control what the component will output which means you are stuck with the look of the component, if you want something that looks different you have to write your own component or you have to modify an existing component. Web browsers are currently evolving very quickly adding new features which can really improve the quality of an application UI but to you those features you have to write HTML, CSS, and JavaScript directly and the server side components make that harder.
Client side component architectures are here and much better than doing components on the server side. Here is my recommend stack.
Client Side Architecture:
jquery.js - Basic libary to make all browser look the same to JavaScript
backbone.js + underscore.js - High level client side component based architecture
handlebars.js - for the client side templates
Twitter bootstrap - to get a decent starter set of CSS & widgets
You write code in HTML, CSS and JavaScript organized as backbone views that talk to server side
models using AJAX. You have complete control over the client side user experience with enough
structure to really make nice reusable code.
Server Side Architecture:
Annotation Driven Spring MVC, Services and Dao (#Controller, #Service, #Repository)
Spring component scanning with autowiring by type (#Autowired, #Inject)
AspectJ Load Time Weaving or Compile Time Weaving
Hibernate
Tomcat 7
JSP as the view technology for Spring MVC (yes it cluncuky but you wont be creating
too many jsp pages, mostly for usng <% #inculde > directive
Tooling:
- Spring Tool suite
- JRebel (so that you don't have to start and stop the server) it really works really worth the money
- Tomcat 7