Tuesday, December 27, 2011

Liferay Portlet Backend: Service Builder Discussion

Is service builder good enough? Are Spring and Hibernate the best option?

When I first started Liferay Portlet development, the first thing I came across with was "Service Builder", my first thought was "this is awful", with the following reasons:

  • It didn't allow me to do TDD but to directly write business code and then generate the interface out of it.
  • It generates a lot of classes, and I'm only allowed to modify a few (just one I think).
  • The resulting code throws a lot of exceptions (the same as the Liferay API) and I'm really not into throwing lots of exceptions.
But as every first step I was able to look at the configuration files it generates and then learn how I could create my own Spring framework context using the same data source as liferay and having a great coding experience with Hibernate and Spring.

Everything seemed fine until I realized that it wasn't the best option, three reasons I can think of right now are:
  • No support for global transactions, this means the transaction my code manages is different than the transaction of the Liferay API calls so no global rollback for me.
  • No support for database sharding, well not precisely but If I wanted it to work transparently, I would have to make my own way through it.
  • No direct relationships of my data model with the Liferay entities, this means no automatic foreign keys for example.
So then I realized that I was trying to kill a fly with a nuclear bomb, this is the fact: You COULD create huge applications with portlets in Liferay but portlets (as any other liferay plugin) are for customizing the web portal and not to build huge applications. 

If we lower down the scale and say a portlet is just a customization:
  • It's so simple we don't need to write many test classes.
  • We may care of having it done quickly and don't care so much if it's THAT pretty.
  • We may want to make things consistent with the existing API.
  • We don't want to miss Liferay features.
Service Builder is great at this, it generates code following many conventions, it generates javadoc and it basically does all the boilerplate for you so you only need to write 10 to 20 lines of business code and that's it.

So as a conclusion I would say that Service Builder is the best option if you're planning to use liferay as a web portal and not as an app container. If you're using it as an app container (which I really don't recommend) and you don't care that much of loosing a couple of liferay features, then you should definitely go with Spring and Hibernate since your life will be a LOT easier and you'll be able to write unit tests and those kinds of thins. 

2 comments:

  1. I would add that you can publish as a web-service any service you create with service-builder just by adding a configuration in the service.xml file. Even more, you can make them json web services just by adding "@JSONWebService" in the LocalServiceImpl class of your custom service.

    HTH

    ReplyDelete
  2. Hi,

    I'm new to Liferay and JSF so please can you give me a simple example showing how to use the generated classes by the service builder to persist and list objects from the database?

    ReplyDelete