DAO模式作为与数据库打交道的东西,他只关注怎么将数据写入数据库,和怎么取出来.
作为DAO中的数据类型他不依赖于任何技术,jdbc也好,hibernate也好,他对你底层的访问提供了很好的支持
例如:UserDao(Interface)
这个时候你可以实现一个UserDaoJdbcImp,也可以实现UserDaoHibernateImp,
在这一层,我们不关心具体的业务逻辑,可以进行单独的测试,是一个独立的模块.利于分工.
而在service层次上,我们更加关注业务,我们要保证业务的完整性,和数据的一制性,我们并不关心底层是jdbc还是hibernate,在这里我们需要向UI层提供Bussiness Logic,也许以后你的实现将会更改成为分布的,需要调用EJB,JMS,或者,webservice,那么我们替换掉serviceImp即可.
通过实现DAO,我们达到了解耦合的目的,达到了饮场实现的目的,使的程序更加的健壮,虽然复杂性是增加了.
作为DAO中的数据类型他不依赖于任何技术,jdbc也好,hibernate也好,他对你底层的访问提供了很好的支持
例如:UserDao(Interface)
这个时候你可以实现一个UserDaoJdbcImp,也可以实现UserDaoHibernateImp,
在这一层,我们不关心具体的业务逻辑,可以进行单独的测试,是一个独立的模块.利于分工.
而在service层次上,我们更加关注业务,我们要保证业务的完整性,和数据的一制性,我们并不关心底层是jdbc还是hibernate,在这里我们需要向UI层提供Bussiness Logic,也许以后你的实现将会更改成为分布的,需要调用EJB,JMS,或者,webservice,那么我们替换掉serviceImp即可.
通过实现DAO,我们达到了解耦合的目的,达到了饮场实现的目的,使的程序更加的健壮,虽然复杂性是增加了.
?
这样说比较抽象,或许你还没明白,特别时(当你的开发中只涉及到一种数据库链接方式hibernate,jdbc或其它的;又或者当你的开发每个service中只涉及一个dao,不牵涉多个表操作,但这种情况比较少)你还是会觉得dao的作用不大。
?
但是,以软件开发思想及面向对象思想考虑,dao还是有必要的――特别是对于比较大型的项目时,分工比较细,为了方便后期维护。当然,没有绝对的技术,开发时应该看需要,看环境灵活应用。
?