关于三层架构中sql语句的问题！

Question

在三层架构中，sql语句应该出现在哪一层？业务逻辑层还是数据处理层？我知道肯定不会在界面层的！
如果是固定的sql语句完全可以不在一二层中出现，但是如果查询比较复杂，例如网页中最常用的组合查询，用户可以任意组合来生成sql语句，也就是说可以生成很多种sql语句，这些sql语句都是动态产生的，那么我在业务逻辑层或者数据处理层又如何定义它们呢？百思不得其解希望高人讲解，最好能用个小例子来说明，谢谢

Answer 1

哪层也不应该在,既然sql 是在DB中生成\使用的,就应该在数据库的sp中!不知道我这么认为是否正确:)

Answer 2

"例如网页中最常用的组合查询，用户可以任意组合来生成sql语句，也就是说可以生成很多种sql语句，"它再复杂也是  AND OR NOT  = <> > < >= <= IN ,BETWEEN  ,NOT IN 拼出来的
你也可以用个界面让用户自己勾他要的条件和几个条件间的 AND OR 关系,
然后 后台用这些来组装 Where 后面的那部分.需要选择的字段同样可以拼装出来的嘛.

Answer 3

有一些数据库的操作是数据库本身直接操作的，比如oracle中写一些triger，处理一些逻辑

Answer 4

举个例子，不知道是否合适，AInfo类中定义Bean，然后ADAO类中进行数据库操作，ABD类中进行操作的实现，进行数据库连接。JSP页面调用struts的action类，action调用ABD进行具体的逻辑操作！！！

Answer 5

哦
    一般SQL语句都应该放在数据层，因为其与底层数据库的交互紧密偶合，但很少甚至不牵涉高层业务逻辑。在通常的应用中都会在数据层与业务逻辑层添加一层数据集成层，用来转换高层业务数据结构与底层数据库数据结构的转换，如果能将SQL语句直接放入数据库中（比如做为存储过程之类的）当然更好，这是因为易于维护，并且性能也会更加出色（当然实际应用中并非总能这样）。
    不过教科书、模式都是死的，人是活的，具体的解决方案应该具体分析，而不是照着书上非要生搬硬抄。一般查询子功能会被许多用例所调用，完全有理由抽象出来成为一个公共的子用例，并对其进行建模，本人的经验也十分有限，所以就个人感觉如果该模块与数据库非常偶合，就应该直接与数据库交互（因为是子功能，与底层的偶合多少是不可避免的）。但为此也必须失去灵活性和扩展性，但总比得不到解决方案而在那边干着急强些，等有了经验之后再回来审视这些问题给出更好的解决方案吧。(建议先将该功能所产生的模块与其他业务逻辑模块隔离开来尽量降低偶合，以免触一发而动全身，HOHO~~~)@.@||~