web-dev-qa-db-fra.com

Responsabilités et utilisation des couches de service et DAO

Je suis en train de développer une application web utilisant Struts2 avec le plugin Spring et hibernate et pendant que je regardais des exemples en ligne, j'ai vu l'utilisation des couches Service et DAO maintenant je me suis rendu compte de l'utilisation réelle des couches objet Service et accès aux données? Si la couche Service appelle simplement les méthodes des couches DAO pour effectuer des opérations CRUD. ne serait-il pas judicieux d'appeler directement les méthodes des couches DAO?

Disons que cet exemple de Dao et de la couche de service

PeopleService

  @Transactional
    public class PeopleService {

        private PeopleDao pDao;

        public PeopleDao getPDao() { return pDao; }

        public void setPDao(PeopleDao peopleDao) { this.pDao = peopleDao;   }

        public void createPerson(String name){
            pDao.createPerson(name);
        }

        public List<Person> getPeople(){
            return pDao.getPeople();
        }

    }

PeopleDao

public class PeopleDao {

    private SessionFactory sessionFactory;

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

    public Session sess() {
        return sessionFactory.getCurrentSession();
    }

    public Person getPersonById(long id) {
        return (Person) sess().load(Person.class, id);
    }

    public void deletePersonById(long id) {
        sess().delete(getPersonById(id));
    }

    public void createPerson(String name) {
        Person p = new Person();
        p.setName(name);
        sess().save(p);
    }

    @SuppressWarnings("unchecked")
    public List<Person> getPeople() {
        return sess().createQuery("from Person").list();
    }

}

Ma question est quelle est l'utilisation réelle des couches de service si elles ne sont injectées que par leur DAO représentatif et appellent ensuite sa méthode?

javajava-eeservicearchitecturedao
30
user962206

C'est une bonne idée d'avoir ces deux couches lorsque votre logique métier est plus complexe que votre logique de données. La couche service implémente la logique métier. Dans la plupart des cas, cette couche doit effectuer plus d'opérations que d'appeler simplement une méthode à partir d'un objet DAO. Et si vous envisagez d'agrandir votre application, c'est probablement la meilleure solution.

Imaginez que vous souhaitez inclure une entité City et créer une relation entre les gens et la ville. Voici un exemple:

@Transactional
public class PeopleService {

    ....
    private PeopleDAO pDAO;
    private CityDAO cDAO;

    ...

    public void createPerson(String name, String city)
     throws PeopleServiceException {
        Person p = new Person();
        p.setName(name);

        City c = cDAO.getCityByName(city);
        if (c == null) throw new ServiceException(city + " doesn't exist!");
        if (c.isFull()) throw new ServiceException(city + " is full!");
        c.addPeople(p);

        sess().save(p);
        sess().save(c);
    }

    ...
}

Dans cet exemple, vous pouvez implémenter des validations plus complexes, comme vérifier la cohérence des données. Et PersonDAO n'a pas été modifié.

Un autre exemple:

couches DAO et Service avec Spring

Définition du modèle de couche de service

44
CarlosMecha

Si votre application se développe avec des exigences nouvelles et changeantes, vous êtes très bien servi d'avoir des couches distinctes pour ces DEUX ASPECTS DISTINCTS (persistance-> DAO, cas d'utilisation commerciale -> services) de votre logiciel.

Un aspect est votre modèle de persistance avec ses relations, validations, transactions et nombreux modèles d'accès.

Les services sont guidés par les cas d'utilisation commerciale qui ont une granularité très différente. Au début, vous pouvez avoir des services très simples qui ne font pas beaucoup plus que d'appeler les DAO pour remettre les données qu'ils ont reçues, disons, d'une page Web. Mais cela est susceptible de changer avec le temps et les services deviendront de petits réseaux d'objets collaboratifs qui en feront beaucoup plus pour servir le cas d'utilisation métier. Si vous n'utilisez pas de DAO,

  • vos services contiendront du code qui traite des objets de requête, de la gestion des transactions, de la validation, tout cela n'a rien à voir avec les besoins réels de l'entreprise
  • le code de service sera désordonné et il sera difficile de savoir quelles parties du code sont réellement liées aux affaires
  • si vous changez ensuite le modèle de persistance, vous pourriez finir par changer de nombreux services

De plus, vous ne pouvez pas facilement tester unitaire votre modèle de persistance mais écrire des tests uniquement sur la couche de service. N'oubliez pas que le découplage et l'encapsulation sont des techniques importantes pour minimiser l'impact du changement.

Quand c'est fait correctement, avoir une couche DAO n'introduira pas beaucoup de surcharge d'implémentation, donc il n'y a pas beaucoup de frais supplémentaires pour l'avoir. Cela sera bientôt payant et vous serez très heureux d'avoir cette couche dédiée.

Consultez cet article: http://codeblock.engio.net/?p=18 . Il est également livré avec une implémentation complète hébergée sur github

10
bennidi