JSF and Hibernate -- Use service-builder or implement own persistence?

[Rico D'Amore, modificado hace 12 años.]

Hi,

I'm relatively new to Liferay.

I've done development with JSF/MyFaces/IceFaces and Hibernate/MySQL.

Traditionally I have Controller and Helper classes along with backing beans all wired together with the annotated POJOS to do the persistence layer implementation with my database. (Backing beans make calls to services which in turn interact with the helper classes to work with the db.

My question is: should this be the way I use JSF/Hibernate/MySQL with liferay? Or, should I make the front end with JSF and then try to use the liferay LocalServiceUtil methods (generated with service-builder) to hit the db? If so, would I use annotations with my backing beans? How exactly can I go about this? The above stated way with JSF/HIbernate/MySQL seems very straight forward to me, but that's because I've already done it a bunch. It seems like I should be leveraging the service-builder from Liferay, but how to do that is a little vague. But: in order to do this it seems like I have to have those annotated POJO classes, but we are not supposed to mess with the service directory that the service-builder creates. :-(

Can anyone point me in the right direction here? I've been scouring the inter-webs, and I've found a lot of posts with people interested in the same thing, and I'm wondering if this community has already solved this problem.

Thanks! So far, I like what liferay is about!

[David H Nebinger, modificado hace 12 años.]

Using SB is recommended for all portlets.

Primarily the reason for this is that you typically have multiple portlets sharing the data services. If you put them directly in the portlet, sharing becomes harder. Worst-case scenario is you have separate portlets, each with their own database connection, hibernate stuff (session factory, cache, etc.), retrieving and updating the same table... Gets to be a mess pretty quickly. It will work, but your runtime memory and resource usage goes up as a result.

The SB side of the house will use a single db connection (or a single pool of connections), single hibernate cache, etc. The portlets themselves just call the LocalServiceUtil guys to get the data they need.

Unfortunately on the SB side annotations are out. You must use the service.xml file and define your entities there (tweak the hints file for size information, add connection stuff to ext-spring.xml if you're not using the liferay database) and then build the services to create all of the various classes, and don't change the files that SB generates (except for the LocalServiceImpl classes where you can add your own methods).

[Rico D'Amore, modificado hace 12 años.]

Okay,

So, with your recommendations in mind, it seems that I could still use a backing bean to get data from an .JSF page, the call the methods existing in LocalServiceImpl to interact with my db. I wouldn't need the traditional config.xml files for beans and such because SB has already managed all of that for me. ext-spring.xml and hints.xml makes perfect sense to me, I just want to make sure I'm thinking about getting data from my JSF pages correctly. Or maybe the backing bean idea is way off?

[Rico D'Amore, modificado hace 12 años.]

I meant the methods that I implemented in LocalServiceImpl, not the methods that were already there.

[David H Nebinger, modificado hace 12 años.]

Yep, your backing bean would contain all of the stuff you'd normally put in there, except instead of going to your hibernate layer you'd go to the LocalServiceUtil classes.

[Neil Griffin, modificado hace 12 años.]

I agree with David. I would just like to add that there are two demo portlets that do this type of thing that might help you with some managed-bean patterns (Lazy Data Loading, etc.):

• ICEfaces3 Users Portlet (shows up in the Control Panel)
• ICEfaces3 Directory Portlet

There is also a generic CRUD type of portlet that provides Mock implementations of generic services. This might be a nice one to start with and retrofit with Hibernate query results:

• ICEfaces3 CRUD Portlet

[Ashish Renapurkar, modificado hace 11 años.]

Neil Griffin:

I agree with David. I would just like to add that there are two demo portlets that do this type of thing that might help you with some managed-bean patterns (Lazy Data Loading, etc.):

• ICEfaces3 Users Portlet (shows up in the Control Panel)
• ICEfaces3 Directory Portlet

There is also a generic CRUD type of portlet that provides Mock implementations of generic services. This might be a nice one to start with and retrofit with Hibernate query results:

• ICEfaces3 CRUD Portlet

ICEfaces3 CRUD Portlet This sample is work for me. Thanks Neil.

Regards...
Ashish

[Neil Griffin, modificado hace 12 años.]

moved thread to Liferay Faces forum

[Ben R, modificado hace 11 años.]

What they said.
Also, for some more Hibernate background information:
http://en.wikipedia.org/wiki/Hibernate_(Java) Wikipedia Hibernate

http://i-proving.com/2006/11/06/hibernate-annotation-examples/ Hibernate Annotation Examples

http://i-proving.com/2005/08/03/user-types-in-hibernate/ Hibernate User Types

http://i-proving.com/2006/09/25/hibernate-annotations/ Hibernate Annotations