Setup Menus in Admin Panel

Service layer

Service layer Quiz

Service layer 

What are models? What is their life-cycle? What services does hybris have? What is the role of the Spring framework in hybris Services? ServiceLayer Interceptors Spring Framework in the hybris Commerce Suite

Structure Overview

The ServiceLayer can be described as a layer of services on top of the persistence layer. The services themselves can be divided into subcomponents. Figure: The ServiceLayer (blue) interconnects the persistence layer with the client. Arrows indicate exchange of data objects.

Architectural Components

Client

A client in this context is any software component that uses the ServiceLayer, such as:

  • Page Controllers of an MVC framework
  • Web Service clients
  • Scripts
  • Other services

Services

A service holds the logic to perform business processes and provides this logic through a number of related public methods. These public methods usually are defined in a Java interface. Most often these methods operate on the same kind of model object, for example product, order, and so on. Services are expected to abstract from the persistence layer, that is, to only contain functional logic and no persistence-related code. That means if you implement a service, make sure to implement it in a way that the underlying implementation is as loosely coupled to the persistence layer as possible.

Figure: Sample of relations between services. Note the pattern of having an interface and an implementation per service. The hybris Commerce Suite exposes all of its functionality through services. The following kinds of services are available:

  • Business Services implement business use cases, such as cart handling or back order.
  • Infrastructure Services provide the underlying technical foundation, such as internationalization, import, export, and so on.
  • System services provide functionality required by the ServiceLayer, such as model handling and session handling.

The service methods should be as fine-grained as possible to enable reuse. Extensions must provide their functionality as services. Per extension you may provide as many services as you deem necessary, not just one. Services may use other services to perform their tasks but should keep their interdependencies to a minimum to avoid overly tight coupling with other components. In a project, you may write your own services to either provide unique functionality or to aggregate other services’ functionality. Although technically not necessary, hybris recommends implementing services in terms of interfaces. See Spring Framework in the hybris Commerce Suite for reasons why. Services interact with other components through models. For details see section Models below.

Strategies

A service may delegate parts of its tasks to smaller micro-services, called strategies. The service then serves as a kind of facade to the strategies. Clients still use the service and its stable API. But under the hood the functionality is split into multiple parts. Because these parts are smaller and very focused to their task, it is easier to adapt or replace them. Strategies therefore help to further encapsulate behavior and make it more adaptable.

Figure: Sample of a service (consisting of an interface definition and the related implementation) relying on strategies. Note how the strategies also follow the pattern of interface definition and related implementation.

DAOs

A DAO (Data Access Object) is an interface to the storage back end system. DAOs store and retrieve objects. You use DAOs to save, remove, and find models. DAOs are the place to put SQL or FlexibleSearch statements and nowhere else. This is to ensure further decoupling from the underlying storage facility. DAOs interact with services via models and with the database viaFlexibleSearch and SQL statements.

In the hybris Commerce Suite, DAOs use the hybris Type System for persistence. This means that hybris Commerce Suite DAOs do not implement any individual logic and simply call the underlying persistence layer.
See also

Models

Models are a new way to represent hybris items. Each model contains all item attributes from all extensions thus unifying access to an item’s data. Models are generated from the type system of the hybris Commerce Suite; see Type System Documentation. Furthermore they are more or less simple POJOs (Plain Old Java Objects) that can be used without any storage facility. Thus, it’s pretty easy to mock them up, for example for testing and debugging. Models are used by DAOs, services, strategies, converters, and facades.
© Pradeep Academy.  Design & Developed by