老生常谈，关于Service和DAO的解耦和

各位前辈好，小弟心中存有疑问良久，望能得到各位前辈的经验之谈。
仍旧是关于Service和DAO之间的耦合性问题。

项目中80%以上的数据库操作是query操作，这意味着我不管使用JDBC或是Hibernate都会存在着要写大量的复杂的SQL或HQL语句进行query的工作。问题就在，到底这些SQL或HQL我应该写在哪里？

一，在DAO中，根据项目需求定义大量用于query的method。这样简化了Service的操作。
但是困惑是，如果这些复杂查询的业务已经被DAO实现了，要Service干吗用？
或者说，DAO作为一个与持久层打交道的层面，不应该与业务逻辑层产生任何耦合性依赖。
但如果将这些查询语句写在DAO中，如果一旦业务改变，DAO中岂非也得相应变化？

二，在DAO中使用通用方法执行查询，而查询使用的SQL或HQL作为方法的参数被调用者（Service）传进来。
这样意味着SQL必须定义在Service里。
如果可以在Service层里写SQL的话，那还需要DAO吗？
或者说，这个Service,还能被称之为Service吗？

三，将SQL或HQL写在配置文件中，
在Service里通过某个诸如SQLUtils之类的类去读取配置文件得到SQL
传递给DAO用于查询。
但同样问题多多，例如在开发时，配置文件是在初始化加载的
意味着我每次修改SQL都得加载项目。

不知道我的问题是否描述清楚，想知道各位前辈的做法

[该贴被admin于2009-03-24 13:13修改过]

>到底这些SQL或HQL我应该写在哪里
写都不该写，用对象设计来编程，将业务从SQL和HQL分离出来，具体见Evans DDD

你这种是典型的数据库思维，方向都错了，你向南已经跑出100公里，想解耦了，向北再回个5公里，不起作用。

对“用对象设计编程”，此举具体如何解决复杂查询的问题，有DEMO吗？banq老师可否给予提示？

不如看看Jdon先

如果又数据持久化层的话，一般的业务流程中是用不到SQL语句的。不过如果最后有统计和报表业务的话，还是要直接查询数据库，这种情况下DAO的作用变小，SQL写在配置文件中应该是不错

回DLUTkaka

就是在项目带有大量的统计和报表业务
导致出现大量复杂查询
普通的orm无法针对这种情况做映射

您是说这种情况应该将SQL写在配置文件中，然后在Service中读取吗？
抑或是根本不使用DAO？

今天在车上又重新考虑了这个问题，banq关于取消数据库的思想确实是对的，但目前的技术很多情况下根本实现不了，

比如象现在这个项目和我所从事的大型ERP软件，这种后期大量的统计和报表，如果用面向对象的思维反而会很复杂，并且效率也将极低。

昨天我说把SQL语句写在配置文件中不错，今天重新想了一下也许并不符合你的需求。
此前我曾在一个网站项目中把SQL写在配置文件中，但是很少，并且比较确定即使以后业务改变，但SQL查出来的数据组织不会变。

不知道你这个项目的具体情况是什么样的，如果统计业务很多并且复杂，恐怕写在配置文件中不合适。因为如果以后业务发生改变而引起SQL语句要改变，基本上程序中相关的代码也是必定要修改的，而且通常这种SQL语句也不会重用。所以倒不如写在程序中了，DAO调用查询就行了。

当然这只是我个人的一些想法。并且我可以说还是新手，大家讨论吧。

顶一下,我现在做的系统,主要是企业管理软件,也是很多报表和查询,经常有很复杂的查询.
一条sql可以很快查询出来,可是用面向对象去做总感觉很复杂,用得不好效率很底,也许是我面向对象的功底还太差吧,希望高手指点.

我觉得很多事情应该具体问题具体分析，而不应该用一种方法解决全部问题，所谓尺有所短寸有所长，应该具体工作具体分析，如果是做一个系统，使用OO的方式进行系统的分析，那么是正确的，如果是领导让你出个报表，偶尔或者很长时间才去做一次的东西，往往写一个SQL语句放在那里更加方便，要明白一切都是工具，人要使用工具，而不要为工具所羁绊。