JSF-SPRING -HIBERNATE architecture. Implementation of bean related best practice

Question

I am developing a web project, and after much research, I decided to continue with JSF + Primefaces, Spring and Hibernate. In developing the architecture of my project, I completed the following approach:

Actor → JSF + PrimeFaces Page ---> Bean Support → Bean Service → Tao → Hibernation

• Bean service and DAO Spring beans with dependency injection.

Now I'm worried about bean support: I plan on using multiple beans support for the user interface page, depending on the type of page I need to make.

Now, for example: For a new user registration page, I have UserProfile.xhtml that uses UserBackingBean. UserBackingBean has a UserServiceBean introduced by spring. UserServiceBean has UserDao introduced by spring.

Now in UserBackingBean, when the user enters the form data from UserProfile.xhtml, I will need to populate the User.java (ORM) domain object.

a) What is the best practice for this? Should I initialize User.java in the constructor on UserBackingBean? Is this the right approach? Please suggest if there is another way?

b) Also, please suggest the above architecture, which I decided for my project? Is this the right approach?

Answer 1

The next general rule is that transaction boundaries are marked in the beans service, so I don’t like changing hibernate POJOs outside the service because I don’t know if the transaction is already running. Thus, from a bean backup, I would call the service level passing by the parameters that the service level should create for hibernate pojo and save it, update, ... etc.

Another way to do this would be to support the bean of an interface defined by a service level, and then transfer the bean support to the service level. For instance.

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); } } 

As for your last question, I am not a fan of JSF, I think JSF has fundamental flaws, because it is a server component based structure. Therefore, my argument against JSF is a general argument regarding server-based components.

The main drawback with server-side basics is that you do not control what the component will output, which means you are stuck in the component image, if you want something to look different, you need to write your own component or You need to modify an existing component. Web browsers are currently developing very fast, adding new features that can really improve the quality of the user interface of the application, but for you there are those features that you need to write HTML, CSS and JavaScript directly, and server-side components make this more difficult.

Client-side component architectures are much better here than running server-side components. Here is my recommended stack.

Client Side Architecture:

• jquery.js - The core library so that all browsers look the same for JavaScript
• backbone.js + underscore.js - High-level client-side architecture
• handlebars.js - for client templates
• Twitter bootstrap - to get a decent starter kit for CSS and widgets

You write code in HTML, CSS and JavaScript, organized in the form of basic representations that speak on the server side of the model using AJAX. You have full control of the client-side user interface with enough to really make good reusable code.

Server architecture:

• Passing Spring MVC annotations, services, and Tao (@Controller, @Service, @Repository)
• Spring scan of components with auto-negotiation by type (@Autowired, @Inject)
• AspectJ Weaving time or compilation of weaving time
• Sleep mode
• Tomcat 7
• JSP as a viewing technology for Spring MVC (yes, it is cluncuky, but you won’t create too many jsp pages, mainly for the usng directive <% @inculde>

Tools: - Spring Toolbox - JRebel (so you don't have to start and stop the server), it really really costs money - Tomcat 7