java - DAO and Service layers (JPA/Hibernate + Spring) -

this question has answer here:

• java ee architecture - dao's still recommended when using orm jpa 2? 2 answers

i'm designing new app based on jpa/hibernate, spring , wicket. distinction between dao , service layers isn't clear me though. according wikipedia, dao

an object provides abstract interface type of database or persistence mechanism, providing specific operations without exposing details of database.

i wondering whether dao contain methods don't have data access, way easier executed using query? example "get list of airlines operate on set of airports"? sounds me more of service-layer method, i'm not sure if using jpa entitymanager in service layer example of practice?

a dao should provide access single related source of data and, depending on how complicated business model, return either full fledged business objects, or simple data objects. either way, dao methods should reflect database closely.

a service can provide higher level interface not process business objects, access them in first place. if business object service, object may created different databases (and different dao's), decorated information made http request. may have business logic converts several data objects single, robust, business object.

i create dao thinking used going use database, or set of business related data, literally lowest level code besides triggers, functions , stored procedures within database.

answers specific questions:

i wondering whether dao contain methods don't have data access, way easier executed using query?

for cases no, want more complicated business logic in service layer, assembly of data separate queries. however, if you're concerned processing speed, service layer may delegate action dao though breaks beauty of model, in same way c++ programmer may write assembler code speed actions.

it sounds me more of service-layer method, i'm not sure if using jpa entitymanager in service layer example of practice?

if you're going use entity manager in service, think of entity manager dao, because that's is. if need remove redundant query building, don't in service class, extract class utilized entity manager , make dao. if use case simple, skip service layer entirely , use entity manager, or dao in controllers because service going pass off calls getairplanebyid() dao's findairplanebyid()

update - clarify regard discussion below, using entity manager in service not best decision in situations there dao layer various reasons highlighted in comments. in opinion reasonable given:

1. the service needs interact different sets of data
2. at least 1 set of data has dao
3. the service class resides in module requires persistence simple enough not warrant it's own dao

example.

//some system contains our customers information class persondao {    findpersonbyssn( long ssn ) }  //some other system store pets class petdao {    findpetsbyareacode()    findcatbyfullname() }  //some web portal building has service class ourportalpetlostandfoundservice {     notifyoflocallostpets( person p ) {       location l = ourportalentitymanager.findsingle( portaluser.class, p.getssn() )         .getoptions().getlocation();       ... use other dao's contact information , pets...    } }