java职责以及服务和DAO层的使用

Question

我目前正在使用Struts2和Spring插件以及hibernate开发一个web应用程序，当我查看在线示例时，我看到了服务层和DAO层的使用，现在我想到了服务层和数据访问对象层的真正用途是什么？如果服务层只是调用DAO层的方法来执行CRUD操作。直接调用DAO层方法是不明智的吗

让我们以Dao和服务层为例

人民服务

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

    }

人民岛

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注入，然后调用其方法，那么服务层的真正用途是什么

Answer 1

如果您的应用程序将随着新的和不断变化的需求而增长，那么对于软件的这两个不同方面（持久性->；DAO，业务用例->；服务），您可以很好地使用不同的层

一个方面是持久性模型及其关系、验证、事务和许多访问模式

这些服务由业务用例驱动，这些用例的粒度非常不同。一开始，你可能有一些非常简单的服务，这些服务除了调用DAO来传递他们从网页接收到的数据之外，没有什么作用。但随着时间的推移，这种情况可能会发生变化，服务将成长为小型协作对象网络，这些对象在服务业务用例方面做得更多。如果不使用DAOs，那么

• 您的服务将包含处理查询对象、事务处理和验证的代码，所有这些都与实际业务需求无关
• 服务代码看起来很凌乱，很难找出代码中与业务相关的部分
• 如果随后更改持久性模型，最终可能会更改许多服务

此外，您不能轻松地对持久性模型进行单元测试，只能在服务层上编写测试。不要忘记，解耦和封装是将更改的影响降至最低的重要技术

如果做得好，拥有DAO层不会带来太多的实现开销，因此没有太多额外的成本。这将很快得到回报，你会很高兴有这个专用层

看看这篇文章：http://codeblock.engio.net/?p=180。它还附带了一个托管在github上的完整实现