Liferay Service Builder is a model-driven code generation tool that lets you define custom object models called entities. Service Builder generates a service layer through object-relational mapping (ORM) technology that provides a clean separation between your object model and code for the underlying database. This frees you to add the necessary business logic for your application. Service Builder takes an XML file as input and generates the necessary model, persistence, and service layers for your application. These layers provide a clean separation of concerns. Service Builder generates most of the common code needed to implement create, read, update, delete, and find operations on the database, allowing you to focus on the higher level aspects of service design. This tutorial explains some of the main benefits of using Service Builder:
- Integration with Liferay DXP
- Automatically generated model, persistence, and service layers
- Automatically generated local and remote services
- Automatically generated Hibernate and Spring configurations
- Support for generating finder methods for entities and finder methods that account for permissions
- Built-in entity caching support
- Support for custom SQL queries and dynamic queries
- Saved development time
Liferay DXP uses Service Builder to generate all of its internal database persistence code. In fact, the services, both local and remote, are generated by Service Builder. Additionally, the service modules are generated by Service Builder. These things demonstrate Service Builder to be a robust and reliable tool. It is easy to use and can save lots of development time. Although the number of files Service Builder generates can seem intimidating at first, you only need to work with a few files to customize to your applications and add business logic.
One of the main ways Service Builder saves development time is by completely
eliminating the need to write and maintain database access code. To generate a
basic service layer, you only need to create a service.xml file and run
Service Builder. This generates a new service .jar file for your project. The
generated service .jar file includes a model layer, a persistence layer, a
service layer, and related infrastructure. These distinct layers represent a
healthy separation of concerns. The model layer is responsible for defining
objects to represent your project’s entities, the persistence layer is
responsible for saving entities to and retrieving entities from the database,
and the service layer is responsible for exposing CRUD and related methods for
your entities as an API. The code Service Builder generates is
database-agnostic, as is Liferay DXP itself.
Each entity Service Builder generates contains a model implementation class.
Each entity also contains a local service implementation class, a remote service
implementation class, or both, depending on how you configure Service Builder in
your service.xml file. Customizations and business logic can be implemented in
these three classes; in fact, these are the only classes generated by Service
Builder that are intended to be customized. Ensuring that all customizations
take place in only a few classes makes Service Builder projects easy to
maintain. The local service implementation class is responsible for calling the
persistence layer to retrieve and store data entities. Local services contain
the business logic and access the persistence layer. They can be invoked by
client code running in the same Java Virtual Machine. Remote services usually
have additional code for permission checking and are meant to be accessible from
anywhere over the Internet or your local network. Service Builder automatically
generates code that makes the remote services accessible. The remote services
Service Builder generates include SOAP utilities and can be accessed via SOAP or
JSON.
Another way Service Builder saves development time is by providing Spring and Hibernate configurations for your project. Service Builder uses Spring dependency injection to make service implementation classes available at runtime and uses Spring AOP for database transaction management. Service Builder also uses the Hibernate persistence framework for object-relational mapping. As a convenience to you, Service Builder hides the complexities of using these technologies. You can take advantage of Dependency Injection (DI), Aspect Oriented Programming (AOP), and Object-Relational Mapping (ORM) in your projects without having to manually set up a Spring or Hibernate environment or make any configurations.
Another benefit of using Service Builder is that it generates finder methods.
Finder methods retrieve entity objects from the database based on specified
parameters. You just need to specify the kinds of finder methods to be generated
in the service.xml configuration file and Service Builder does the rest. The
generated finder methods let you, for example, retrieve a list of all entities
associated with a certain site or a list of all entities associated with a
certain site and a certain user. Service Builder not only supports generating
these kinds of simple finder methods but also finder methods that take Liferay’s
permissions into account. For example, if you are using Liferay’s permissions
system to protect access to your entities, Service Builder can generate a
different kind of finder method that only returns entities that the logged-in
user has permission to view.
Service Builder also provides built-in caching support. Liferay caches objects
at three levels: entity, finder, and Hibernate. By default, Liferay uses
Ehcache as an underlying cache provider for each of these cache levels. However,
this is configurable via portal properties. All you have to do to enable entity
and finder caching for an entity in your project is to set the
cache-enabled=true attribute of your entity’s <entity> element in your
service.xml configuration file. Please refer to the
Liferay Clustering
documentation for more details about Liferay caching.
Service Builder is a flexible tool. It automates many of the common tasks associated with creating database persistence code but it doesn’t prevent you from creating custom SQL queries or custom finder methods. Service Builder lets you define custom SQL queries in an XML file and implement custom finder methods to run the queries. This is useful, for example, for retrieving specific pieces of information from multiple tables via an SQL join. Service Builder also supports retrieving database information via dynamic query. Liferay’s dynamic query API leverages Hibernate’s criteria API.
In summary, we encourage you to use Service Builder for application development because it’s a proven solution used throughout Liferay DXP and Liferay DXP applications. It generates distinct model, persistence, and service layers, local and remote services, Spring and Hibernate configurations, and related infrastructure without requiring any manual intervention. It also lets you generate basic SQL queries and finder methods and methods that filter results, taking Liferay permissions into account. Service Builder also supports entity and query caching. Each of these features saves lots of development time, both initial development time and time that would have to be spent maintaining, extending, or customizing a project. Finally, Service Builder is not a restrictive tool: it lets you add custom SQL queries and finder methods and it also supports dynamic query.