livello di servizio sono tenuti alla tecnologia DB in un'applicazione di primavera

Question

la mia domanda è:? Sono il tuo livello di servizio destinato a tecnologia si utilizza

Ad esempio, se si utilizza Hibernate, che mettete nel vostro livello di servizio alcuni HQL-query o criteri-query che sono vanno in letargo soltanto caratteristiche o chiamare semplicemente DAO (e dao ha implementazione Hibernate, e l'implementazione forse JDBC, ecc ..) ?

Ho qualche difficoltà a costruire un'architettura a strati efficiente per il mio software.

Modifica Questo è un servizio semplice ... penso che sia un servizio ... senza limite di tecnlogy i utilizzando (hibernate)

@Repository
public class PersonHibernateDAO implements PersonDAO {

    @Autowired
    SessionFactory sessionFactory;

    ... dao crud operations(implementation of PersonDAO interface) using sessionfactory ...

    //and some hibernate features methods
    public Person findByCriteria(Criterion criterion){
        // code
    }
}

@Service
public class PersonService {

    @Autowired
    private PersonDAO personDao;

    @Autowired
    private AccessDAO accessDao;

    @Transactional
    public boolean hasPermission(String username, String accessCode){
        Person p=personDao.findByUsername(username);
        Access a=accessDao.findByCode(accessCode);
        ... etc ...
    }
}

E questo è un servizio con implementazione uso Dao

@Service
public class PersonService {

    @Autowired
    private PersonDAO personDao;

    @Autowired
    private AccessDAO accessDao;

    @Transactional
    public boolean hasPermission(String username, String password){
        Person p=((PersonHibernateDao)personDao).findByCriteria(Restrictions.eq("username", username);
        ... etc ...
    }
}

Quale di questi due approccio è giusto?

---

EDIT2

Quindi, per riassumere quello che ho capito:

// BASE DAO INTERFACE
public interface DAOInterface<EntityClass, IDType extends Serializable> {
    EntityClass get(IDType id);
    EntityClass findById(IDType id);
    EntityClass save(EntityClass entity);
    EntityClass update(EntityClass entity);
    void delete(EntityClass entity);
}

// AN HIBERNATE IMPLEMENTATION
public abstract class HibernateDAO<EntityClass, IDType extends Serializable> implements DAOInterface<EntityClass, IDType> {

    @Autowired
    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory){
        this.sessionFactory=sessionFactory;
    }

    public void getSessionFactory(){
        return this.sessionFactory;
    }

    // Implements all DAOInterface method using sessionFactory

}

// PERSON DAO INTERFACE
public interface PersonDAO extends DAOInterface<Person, Long>{

    Person findByName(String name, String surname);
    List<Person> getInAgeRange(int year1, int year2);
}

// PERSON HIBERNATE DAO IMPLEMENTATION
public PersonHDAO extends HibernateDAO<Person, Long> implements PersonDAO{

    // Implements the methods of PersonDAO interface using sessionFactory
}

@Service
public class PersonService {

    //spring inject the correct DAO by its xml config(in this case PersonHDAO
    @Autowired
    private PersonDAO personDAO; 

    // spring manage the transaction
    @Transactional
    public List<Person> getInAgeRange(int year1, int year2){
        return personDAO.getInAgeRange(year1, year2);
    }

}

// NOW... HOW USE IT
//let's assume i have a button, pressing it a table will be populated with all persons in age range
private void actionPerfom(ActionEvent e){
    List<Person> list=personService.getInAgeRange(age1Spinner.getValue(), age2Spinner.getValue());
    //Load a table with list
}

Ci scusiamo per questo muro di testo, forse può essere utile per gli altri mi auguro, im vanno nella direzione giusta? Il mio livello di servizio ha bisogno di un interfaccia? È tutto corectly uno strato? Ho bisogno di un livello di controllo troppo?

Grazie.

Answer 1

Il mio suggerimento:

per i grandi progetti, utilizzare un, interfaccia basata strato DAO dedicato. Non lasciate che il vostro servizio sapere strato nulla della tecnologia di persistenza sottostante. Usare Hibernate / JPA / JDBC / JDO / qualunque cosa solo nello strato DAO.

per i piccoli progetti può essere giusto per avere un livello di servizio solo (soprattutto in considerazione del fatto che sia Session Hibernate e JPA EntityManager espongono comportamento DAO la maggior parte di serie out of the box.

regola di base del pollice: se stai facendo un cambiamento di tecnologia, assicurarsi è necessario solo cambiare uno strato della vostra applicazione

Aggiornamento: , ecco un'interfaccia esempio DAO. Il tuo livello di servizio sarebbe solo codice contro questa interfaccia, e l'implementazione farebbe sessione / entityManager / JDBC chiamate senza il livello di servizio che hanno bisogno di sapere.

public interface CustomerDao extends CommonDao<Customer>{
    Customer getCustomerByEmail(String emailAddress);
    List<Customer> getCustomersWithinAgeRange(int lowerBound, int upperBound);
}

La chiave:. Nel livello di servizio, specificare le dipendenze interfaccia basata-, cioè

private CustomerDao customerDao;
public void setCustomerDao(CustomerDao customerDao){
    this.customerDao = customerDao;
}

anziché

// this is horrible, it ties the service layer to implementation
// details of the dao layer
private HibernateCustomerDaoImpl customerDao;
public void setCustomerDao(HibernateCustomerDaoImpl customerDao){
    this.customerDao = customerDao;
}

Answer 2

Il DAO è il posto per qualsiasi database specifico interrogazione -. JDBC o Hibernate nel vostro caso

Il livello di servizio è pensato per offrire un'API per i consumatori come un livello di presentazione o di altri. Non ci sarebbe alcun motivo per inquinare il livello di servizio con le specifiche del database. Il tuo livello di servizio potrebbe avere la logica di business che va bene, ma non dovrebbe essere a conoscenza della realizzazione DB sottostante IMO