This article is based on Liferay in Action, to be published on August, 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]
Liferay’s Service Builder encourages the proper layering of functionality within a portlet application. Generally, when building an application, it’s good practice to separate the various layers of the application: UI, model, persistence, and so on. This is sometimes called separation of concerns. By keeping the layers as separate as possible, you gain the ability to change the implementation of any one layer more easily—if for some reason you find a better way to do it later.
To some, this must seem like some unnecessary work, but let me give you an example as to why this is important.
The spaghetti code story
Suppose you have a poorly designed application that consists of only two layers—your JSPs and your portlet class. You develop the application by creating action URLs in your JSPs, which correspond to various methods within the portlet. These methods use JDBC to connect to a database and select, insert, update, and delete data. Your database, validation, and page navigation code is all in the portlet or the JSPs, resulting in very large files with lots of logic in them. You test the portlet as well as you can, and it then gets deployed to production.
Within the first day of its use, a bug is found. Your application has a last name field, and a user tried to insert the last name O’Bannon. Because you coded all of your database interaction manually, you forgot that sometimes you need to escape out certain characters. In this case, the apostrophe in the name is causing your database insert to fail.
With the poor design you used for your portlet, you’ll now have to modify the Insert and Update methods of your portlet class and add some code that checks the values your users are inserting for apostrophes. This is an example of a tightly-coupled design: your database code is inside your portlet, so your implementation of code that communicates with the database is intertwined with your business and display logic. Because you were recently working on this portlet, you know where the problem is and so you fix it and redeploy the application. The users work with it for several months before another bug is found. It seems that, somewhere in the portlet, a database connection isn’t being closed and is causing the database server to run out of connections.
If you had properly layered your application so that the UI code was in one place, the business logic was another, and the persistence logic was in another, you’d have a much more maintainable project. And you might decide at that point that you could use something like Hibernate for your database persistence, and you’d only have to replace a few classes in the one layer. Doing that would solve all of your persistence problems, because Hibernate escapes characters and closes connections automatically. You might then go another step further and replace your homegrown application logic with an MVC framework like JSF or Struts. On each refactor, you could modify one layer of your application at a time. Let’s see how to do that for the persistence layer.
Using two layers for persistence
While the above is a simplistic example, it serves as an example we can use to show how Service Builder encourages proper separation of concerns. For database persistence, two of these layers are the Data Access Object and the Data Transfer Object (see figure 1). These two layers can be written by developers manually, and often a lot of time is spent writing and debugging code in this layer. Service Builder automatically generates both layers for you.