java - implement - dao pattern

Responsabilidades y uso de Service y DAO Layers

Question

Actualmente estoy desarrollando una aplicación web usando Struts2 con Spring plugin e hibernate y mientras miraba ejemplos en línea vi el uso de las capas Service y DAO ahora me vino a la mente cuál es el uso real de Service y las capas de objetos de acceso a datos. Si la capa Servicio está llamando a los métodos de las capas DAO para realizar operaciones CRUD. ¿No sería sensato simplemente llamar a los métodos de capas DAO directamente?

Digamos este ejemplo de Dao y Service Layer

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();
    }

}

Mi pregunta es, ¿cuál es el uso real de las capas de servicio si solo están siendo inyectadas por su representante DAO y luego llaman a su método?

Answer 1

Es una buena idea tener esas dos capas cuando la lógica de su negocio es más compleja que su lógica de datos. La capa de servicio implementa la lógica comercial. En la mayoría de los casos, esta capa tiene que realizar más operaciones que simplemente llamar a un método desde un objeto DAO. Y si está pensando en agrandar su aplicación, esta es probablemente la mejor solución.

Imagine que desea incluir una entidad de la ciudad y crear una relación entre las personas y la ciudad. Aquí hay un ejemplo:

@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);
    }

    ...
}

En este ejemplo, puede implementar validaciones más complejas, como verificar la consistencia de los datos. Y PersonDAO no ha sido modificado.

Otro ejemplo:

Capas DAO y Service con Spring

Definición del patrón de capa de servicio

Answer 2

Si su aplicación crecerá con requisitos nuevos y cambiantes, está muy bien servido con tener distintas capas para esos DOS ASPECTOS DISTINTOS (persistencia-> DAO, caso de uso comercial-> servicios) de su software.

Un aspecto es su modelo de persistencia con sus relaciones, validaciones, transacciones y muchos patrones de acceso.

Los servicios son impulsados ​​por los casos de uso comercial que tienen una granularidad muy diferente. Al principio puede tener servicios muy simples que no hacen mucho más que llamar a los DAO para entregar los datos que recibieron de, digamos, una página web. Pero es probable que esto cambie con el tiempo y los servicios se conviertan en pequeñas redes de objetos colaboradores que hacen mucho más para servir al caso de uso comercial. Si no usa DAO entonces

• sus servicios contendrán código que se ocupa de consultar objetos, manejo de transacciones, validación, todo lo cual no tiene nada que ver con los requisitos comerciales reales
• El código de servicio se verá desordenado y será difícil averiguar qué partes del código están realmente relacionadas con el negocio.
• Si luego cambia el modelo de persistencia, puede terminar cambiando muchos servicios

Además, no puede probar su modelo de persistencia fácilmente, sino solo escribir pruebas en la capa de servicio. No olvide que el desacoplamiento y la encapsulación son técnicas importantes para minimizar el impacto del cambio.

Cuando se hace bien, tener una capa DAO no implicará demasiada sobrecarga de implementación, por lo que no hay un costo adicional para tenerla. Pronto valdrá la pena y estará muy contento de tener esta capa dedicada.

Mira este artículo: http://codeblock.engio.net/?p=180 . También viene con una implementación completa alojada en github