Describe an item model and its finder methods -- get the DAO interface/impl, a service layer on top, and the Spring beans wiring it together.
🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.
trainingcore/src/com/prospect2p/core/daos/ItemDao.javapackage com.prospect2p.core.daos;
import com.prospect2p.core.model.ItemModel;
public interface ItemDao
{
// no finder methods configured yet
}
A DAO (Data Access Object) in SAP Commerce (Hybris) is the layer that talks FlexibleSearch so the rest of the codebase doesn't have to -- a small interface plus a Default*Dao implementation backed by FlexibleSearchService, each finder method building a parameterized query and returning model objects (never raw ResultSet rows).
Convention is to never expose the DAO directly to facades/controllers -- a thin service interface/implementation sits on top, delegating to the DAO, so business logic has one stable seam even if the query layer changes underneath it.
Use a custom DAO whenever you need to look up model instances by anything beyond what DefaultGenericDao's generic find-by-example already covers -- a specific WHERE clause, an ORDER BY, pagination, or a join across relations.
If a lookup is truly a plain "find all X where attribute = value" with no special ordering or paging, DefaultGenericDao (or Spring's findValues with a PK) may already do the job without a custom class at all.
DefaultGenericDao's findByExample-style lookups cover simple equality searches with no custom logic. Reach for a FlexibleSearchService-backed DAO (what this generator produces) as soon as you need a specific WHERE/ORDER BY, a join, or pagination -- anything DefaultGenericDao's generic API can't express.
addQueryParameter("customer", customer) lets FlexibleSearchQuery handle type conversion and escaping for you -- string-concatenating a value into the query text is fragile (quoting, type formatting) and reopens a class of injection risk the parameterized API exists specifically to close.
A paginated finder takes a PageableData parameter and calls PaginatedFlexibleSearchService.search(query, pageableData) instead of the plain FlexibleSearchService, returning a SearchResult<T> that carries both the page of results and paging metadata (total count, page size).
The service interface is the stable contract the rest of the app depends on. If the underlying query implementation ever needs to change -- a different index, a caching layer, a completely different data source -- only the service impl changes; every facade/controller that depends on the service interface is unaffected.
Use an integration test extending ServicelayerTransactionalTest (or the project's equivalent base class) that imports known ImpEx test data, then asserts the finder returns exactly the expected rows -- a DAO test is one of the few places hitting the real database is the right call, since the whole point is verifying the FlexibleSearch query itself.