Обязанности и использование Уровней обслуживания и DAO

В настоящее время я разрабатываю веб-приложение с использованием Struts2 с плагином и спящим Spring, и, когда я смотрел онлайн-примеры, я видел, как использование слоев Service и DAO теперь стало для меня реальным использованием Службы и данных слои объектов доступа? Если уровень сервиса просто вызывает методы слоев DAO для выполнения операций CRUD. не было бы разумным просто называть методы слоев DAO напрямую?

Скажем, этот пример Dao и 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();
    }

}

Мой вопрос в том, что является реальным использованием Уровней обслуживания, если они только вводятся их представительным DAO, а затем вызывают его метод?

Ответы

Ответ 1

Это хорошая идея иметь эти два уровня, когда ваша бизнес-логика более сложна, чем ваша логика данных. Уровень обслуживания реализует бизнес-логику. В большинстве случаев этот уровень должен выполнять больше операций, чем просто вызов метода из объекта DAO. И если вы планируете увеличить свое приложение, это, вероятно, лучшее решение.

Представьте, что вы хотите включить объект City и создать отношения между людьми и городом. Вот пример:

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

    ...
}

В этом примере вы можете реализовать более сложные проверки, такие как проверка согласованности данных. И PersonDAO не был изменен.

Другой пример:

Уровни DAO и Service с Spring

Определение шаблона уровня обслуживания

Ответ 2

Если ваше приложение будет расти с новыми и изменяющимися требованиями, вам будет очень хорошо обслуживаться с наличием разных уровней для этих ДВУХ ОТЛИЧНЫХ АСПЕКТОВ (persistence- > DAO, business use case → services) вашего программного обеспечения.

Одним из аспектов является ваша модель персистентности с ее отношениями, проверками, транзакциями и многими шаблонами доступа.

Услуги основаны на случаях использования бизнеса, которые имеют очень разную степень детализации. Вначале у вас могут быть очень простые сервисы, которые не намного больше, чем вызов DAO для передачи полученных данных, например, через веб-страницу. Но это со временем изменится, и службы будут развиваться в небольшие сети сотрудничающих объектов, которые делают намного больше, чтобы служить делу бизнеса. Если вы не используете DAO, то

  • ваши службы будут содержать код, который обрабатывает запросы объектов, обработку транзакций, проверку, все из которых не имеет ничего общего с реальными бизнес-требованиями.
  • код службы будет выглядеть беспорядочным, и будет сложно узнать, какие части кода фактически связаны с бизнесом.
  • Если вы затем измените модель персистентности, вы можете в конечном итоге изменить многие службы.

Также вы не можете легко unit test сохранить свою модель сохранения, но пишите тесты только на уровне сервиса. Не забывайте, что развязка и инкапсуляция являются важными методами минимизации воздействия изменений.

Когда все будет правильно, наличие уровня DAO не приведет к большим накладным расходам, поэтому затраты на его добавление не потребуются. Он скоро окупится, и вы будете очень рады иметь этот выделенный слой.

Ознакомьтесь с этой статьей: http://codeblock.engio.net/?p=180. Он также поставляется с полной версией, размещенной на github