SSH框架中，在各层间，大家解藕合了吗

2011-01-04 04:22:18 459 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

ruoye_2008 墨衍会员 · AI 创作全网分发关注 + 加入社区

CRM+数字人客服：基于Linly-Talker的永久在线接待方案在客户关系管理（CRM）系统中，响应速度与客户体验直接挂钩，而传统人工客服的时段限制和重复问答效率问题，往往是转化流失的痛点。智能客服技术通过AI对话、语音交互与自动化应答，正成为企业服务升级的关键路径。数字人作为智能客服的进阶形态，融合了语音合成、自然语言处理与虚拟形象驱动，不仅提供7x24小时在线接待，还能以拟人化方式提升用户亲近感。开源方案Linly-Talker为这一场景提供了完整流水线，支持对话引擎、ASR、TTS与数字人驱动，并可通过API集成嵌入既有业务系统。本文以一套运行两年的CRM系统升级阅读详情

主要是在Dao层与其它层之间。

以前奉行的宗旨是：只有DAO层与数据库打交道，所有的SQL或HQL都在这层写，不要含任何业务逻辑，最好的话，连一个if语句也不要有。

可现在发现所用的一些框架中，基本上都是写个公共的带泛型的IBaseDao，封装了所有的操作方法。所有的模块都实现这些接口（如UserDao implements IBaseDao），然后在Service层调用这些方法即可，这就造成了所有的HQL语句，都是在Service层的。

更有甚者，通过泛型，封装好Service层和Dao层，HQL语句直接写在Action层里。

确实，这样做的话，能加快开发的进度，减少不少时间，但这种与平常所提倡的各层间的松藕合，似乎...

请问下，对于这方面，大家平时是怎么做的？

...全文

RocketMQ5.3.0-control-多 Master 多 Salve-异步复制-集群搭建 RocketMQ5.3.0-control-多 Master 多 Salve-异步复制-集群搭建（详细文档）阅读详情

ruoye_2008

Java EE 67,535 成员 225,843 内容

+ 关注 + 加入社区

切换为时间正序

ruoye_2008 2011-01-07

打赏
举报

[Quote=引用 36 楼 magicluo 的回复:]
说实话，你这的父类的Dao接口设计就有问题，它并不健壮，已经依赖了Hibernate的api来实现了，如果父类的Dao接口应该是和具体实现是无关的。

我觉得比较好的父DAO接口设计是先设计一个和具体ORM的BaseDao<T> ,只针对单个实体（单表）进行的CRUD简单方法进行定义。
……
[/Quote]

确实，这个父接口并不健壮

magicluo 2011-01-06

打赏
举报

[Quote=引用 29 楼 ruoye_2008 的回复:]
标准的做法应该是所有的HQL语句都写在Dao层的，这样可维护性及后期开发修改，都比较方便

但如果直接写在Service层或 Action层，开发效率要高些
[/Quote]

开发时高了，维护时候你会头大..
特别是大项目上千个类的时候..

magicluo 2011-01-06

打赏
举报

[Quote=引用 6 楼 ruoye_2008 的回复:]
我主要想问的是，那些HQL语句，你们是写在哪层？

我觉得应该只能在Dao，可实际中，大多都写在Service层里了

比如说：
BaseDao:有个方法
List<T> findObject(String queryString, Object[] obj);

在Service层里，就直接写个
String queryString = "..."
baseDao.findO……
[/Quote]

说实话，你这的父类的Dao接口设计就有问题，它并不健壮，已经依赖了Hibernate的api来实现了，如果父类的Dao接口应该是和具体实现是无关的。

我觉得比较好的父DAO接口设计是先设计一个和具体ORM的BaseDao<T> ,只针对单个实体（单表）进行的CRUD简单方法进行定义。

你再设计一个HibernateGenericDao<T>继承自BaseDao<T>,然后你的其他的具体的dao接口，比如departmentDao 就直接继承自HibernateGenericDao 就完了.

如果你用其他的实现，比如Ibatis,你可以写个和ibatis耦合的IbatisGenericDao来继承自baseDao。

至于你dao中的方法，hql肯定是写在dao中，毫无疑问的。因为service层会调用dao层的方法来实现自己的逻辑，service层中的接口肯定也是和中间持久层的api方法没有耦合的。

你这个 findObject 方法，应该写在你的具体的HibernateGenericDao 接口中，而不是在你的baseDao中。

你应该写一个通用多条件的findObject方法，然后针对常用的各种情况，你写个简单的带参方法然后调用这个方法即可。

分层不是教条主义，但在实现功能的前提下要尽量符合满足设计原则。

juyang0303 2011-01-06

打赏
举报

dao层主要进行一些基本的数据操作
service调用dao实现业务逻辑
action调用service实现具体功能

city223 2011-01-06

打赏
举报

我的HQL语句基本上写在service层里面

huanhuaxi_ 2011-01-06

打赏
举报

[Quote=引用 2 楼 chenggm 的回复:]
dao层进行数据库操作
service调用dao，可能调用多个dao，主要业务逻辑操作
action调用service，页面参数的校验，相关显示内容的转换
[/Quote]

确实是这样的。

tt986101dpc 2011-01-06

打赏
举报

[Quote=引用 29 楼 ruoye_2008 的回复:]

标准的做法应该是所有的HQL语句都写在Dao层的，这样可维护性及后期开发修改，都比较方便

但如果直接写在Service层或 Action层，开发效率要高些
[/Quote]

个人感觉。还是写在Dao层比较好点，维护起来比较方便。其实java本身相对其他开发语言而言开发比较复杂但维护方便。。
前阵子。。为了修改公司的网站。结果是用PHP写的、不是一般的乱。。后期维护特别麻烦

jxdwinter 2011-01-06

打赏
举报

我的HQL语句基本上写在service层里面

tomzhou3 2011-01-06

打赏
举报

如果项目是用SSH框架的话,那用跟数据库打交通的话就用Hibernate来实现,Hibernate来负责实现Dao层

dinghun8leech 2011-01-05

打赏
举报

比较常见的解耦比如改变调用者与被调用者的关联方式、动态的给原有服务添加新的服务等。在思想层面，通常就是“每一层只做自己负责的事，不要“多管闲事”。
一般公司使用这些框架，也是便于管理，整理出一套完整的架子和流程，方便我们这些码农在他们留好的一个个坑里填上所需的代码，而这些代码往往又是对已有的高度封装的服务的一个组合调用。

dinghun8leech 2011-01-05

打赏
举报

连一个if都不给写，这太教条了吧。
有时候分层解耦还是要看项目实际情况的，一个极简单的1人月的小web项目，你甚至可以直接在jsp里调javaBean，甚至可以在jsp里写sql。
我一般理解为，理论上dao层向下从db层获取可用连接，将po转为sql/hql去执行，向上层提供了用po实例与数据库交互的服务，一个po的dao即提供了该po对应的物理表的原子操作，那么service可按业务来分，一个业务根据需要，调用多个dao完成一系列操作，更复杂的业务来向下调用基础业务，并在action里来选择控制这些业务。数据库操作最常见的无非是curd，于是这几个典型的动作被抽到了dao的超类中，由具体的dao去扩展原有动作和加上自己独有的动作，这个也很正常。
有些事情这样做大家都知道好，但是不是一定要这么做，不要觉得奇怪。

我在肖申克 2011-01-05

打赏
举报

很久不要DAO层了, 直接在service层的实现类里搞定, hql语句, 没什么太多内容, 干脆不要DAO了, 哈哈

happyfmy 2011-01-05

打赏
举报

[Quote=引用 7 楼 ruoye_2008 的回复:]
Service层有些if else 等，是蛮正常的，不然，Service层就太悠闲了
[/Quote]
确实 dao层主要就是处理一些持久化的东西和数据库打交道
service层来处理业务逻辑
个人感觉还是最初始的比较分得清楚

至于继承BaseDao在service中使用sql等，除了方便开发泛型滥用之外感觉不太好

wang_shx 2011-01-05

打赏
举报

首先要搞清楚为什么要用模式，为什么要耦合？
目的不外乎2个，一个是提高效率，一个是便于维护。
只要是从这个2个角度出发，我觉得就可以了，而不是一定要求web、server、dao各个层之间只能写什么。对于每个项目来说，都有不同的要求，也就意味着，同样的wen需求，有的在web这里就可以完成，有的呢，则在
Business这里，有的数据处理呢，在Dao，有的呢，则需要拿到Business这里。
总而言之就是具体情况具体对待，而不能一个模式到处套用