Whats the difference between a Jalo layer and a service layer in the Hybris commerce suite? I will really appreciate if someone could give an example along with. I know Jalo layer has been deprecated but still if I have to specify which layer to use in my platform then where will I tell Hybris or how will I tell Hybris to use a specific layer?
I think it's best if you read up on the quite good hybris wiki regarding both:
Jalo: https://wiki.hybris.com/display/release5/Jalo+Layer
Service layer: https://wiki.hybris.com/display/release5/ServiceLayer
You won't have to specify which one you use (they are both always running) and if you start a new project you basically must (or at least really really should!) use the service layer exclusively as Jalo will go away (so they say at least for quite some time) in one of the next major releases. In a nutshell, Jalo is the old persistence mechanism while service layer was introduced to address various problems the jalo layer had (performance/caching, extensibility, etc etc).
So if you will be only/mostly working on new projects you probably won't have to acquire too much knowledge about the jalo layer, but if you plan on becoming a hybris consultant or work on old legacy hybris code you will have to deal with Jalo more.
A small example:
In your items.xml files (where you declare your data model) you can specify a jaloclass
attribute which while make the platform create a Java class for you.
E.g.: core-items.xml has Product
declared with jaloclass="de.hybris.platform.jalo.product.Product"
.
The platform automatically also creates the respective servicelayer class (always called *Model.java
, so e.g. de.hybris.platform.core.model.product.ProductModel
.
One limitation of the jalo layer is e.g. that if you want to extend the Product item type in one of your own extensions with some attribute, the newly created attribute will not be at the Product
jalo class (as it resides in the platform and is created only once), but instead it will be available on your extensions Manager class which is a bit unintuitive and cumbersome. The service layer creates all of its model classes only after analyzing and merging all registered extensions and therefore is able to add that attribute at the actual ProductModel
class.
There are many more differences, so if you have more concrete questions feel free to ask them :)
In the past, persistence and business logic was written in the Jalo Layer. After introducing the Service Layer, the existing business logic in Jalo Layer is being moved to the Service Layer. With this, the first goal of the migration to the Service Layer is that all Jalo related classes should not contain any code. As the Jalo Layer should not contain business logic anymore, the public API will be much smaller in the future. It will mainly consist of the means to query flexible searches and a generic way to save and remove data. This functionality is already provided in the Service Layer by adapter services like FlexibleSearchService and ModelService. In this case, any access to the Jalo Layer is no longer encouraged. The second goal is to eliminate all Jalo access in existing classes of the Service Layer.
source : Visit https://wiki.hybris.com/pages/viewpage.action?spaceKey=release5&title=Transitioning+to+the+ServiceLayer
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With