Jalo Layer vs Service Layer

Question

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?

Downer

Answer 1

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 :)

Vally

Answer 2

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

Confession

Answer 3

In first Hybris versions Logic was attached to generated item type classes trough the Jalo (Jakarta Logic) layer, in order to be more flexible Hybris is now moving everything to the more flexible approach of a service layer (not finished yet, promotions are a good example of legacy Jalo layer).

Reprehend

Answer 4

Based on after reading of the above answers and did one practice based on the first answer my conclusion is following:

Yes, JALO's non-abstract class implementation is moved as *Model.java for writing more specific business logic including the good explanation in first 2 answers.

Cheers,

Creation