couche de service sont liés à la technologie DB dans une application à ressort

Question

ma question est: Est-ce que votre couche de service liée à tecnologie vous utilisez

Par exemple, si vous en utilisant mise en veille prolongée, vous mettez dans votre couche de service des HQL requêtes ou critères des requêtes qui sont hibernent seulement des fonctionnalités ou vous suffit d'appeler DAO (et dao a la mise en œuvre mise en veille prolongée, et la mise en œuvre peut-être jdbc etc ..) ?

J'ai du mal à construire une architecture en couches efficent pour mon logiciel.

EDIT Ceci est un service simple ... Je pense que c'est un service ... sans lié à tecnlogy i en utilisant (veille prolongée)

@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 ...
    }
}

Et ce service est la mise en œuvre de l'utilisation 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 ...
    }
}

Wich de ces deux approche est juste?

---

EDIT2

Alors, pour résumer ce que je compris:

// 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
}

Désolé pour ce mur de texte, peut-être être utile pour les autres, je l'espère, im aller dans la bonne direction? Ma couche de service ont besoin d'une interface? Est-ce tout corectly posés? J'ai besoin d'une couche de contrôle trop?

Merci.

Answer 1

Ma suggestion:

pour les grands projets, utiliser une couche DAO dédiée, basée interface. Ne laissez pas votre couche de service savoir quoi que ce soit sur la technologie de persistance sous-jacente. Utilisez Hibernate / JPA / JDBC / JDO / whatever uniquement dans la couche DAO.

pour les petits projets, il peut être acceptable d'avoir une couche de service uniquement (en particulier compte tenu du fait que les deux Hibernate et JPA Session EntityManager exposent plus standard le comportement de DAO de la boîte.

Règle de base: si vous faites un changement de technologie, assurez-vous que vous avez seulement besoin de changer une couche de votre application

Mise à jour: Voici un exemple interface DAO. Votre couche de service serait que le code contre cette interface, et la mise en œuvre ferait la session / entityManager / jdbc appels sans la couche de service besoin de connaître.

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

La clé:. Dans votre couche de service, définir en fonction de l'interface de vos dépendances, i.e.

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

au lieu de

// 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

Le DAO est l'endroit idéal pour une interrogation spécifique de base de données -. JDBC ou Mise en veille prolongée dans votre cas

Le niveau de service est destiné à offrir une API aux consommateurs comme une couche de présentation ou d'autres. Il n'y aurait aucune raison de polluer le niveau de service avec des détails de base de données. Votre niveau de service peut avoir une logique d'affaires qui est très bien, mais il ne devrait pas être au courant de la mise en œuvre sous-jacente de l'OMI DB