是否应去除持久层的JPQL,HQL,EJB QL

miaofm 2011-03-01
个人体会在项目中这些对象查询语言,有些鸡肋。整个就是就是sql和对象的结合体,既然不能做到完全对象化,干脆就不提供对象查询语言。

个人认为持久层应该是jpa的标注实现(增、删、改)和spring——jdbc的查询相结合。不用提供什么对象查询语言,你要查复杂的查询语句,就得自己写原始的sql,再封装为vo对象。

以上为个人体会,希望大家踊跃发表~~,谢谢!
凤舞凰扬 2011-03-03
   如果是谈持久层的实现,这些东西无可厚非,不在此处又在何处? 上述的QL与传统的QL区别就在于不会有数据库差异,这也是持久层最为重要的一个设计之处。如果直接使用jdbc,作为项目而言,问题不大(一般也不会换数据库),作为产品,就会存在问题了。
    使用QL的第二个优势其实就是ORM本身具备的优势了,包括实体映射和查询缓存,这些东西都是传统JDBC没做的,自己做也不是不行,只是能确保做好么?
    至于后面谈到了VO对象,也就是值对象,呵呵,确实,它和实体对象也就是域对象是有区别的,可以看我2004年的帖子关于这些的讨论。
    当然了,说到这里,也不是说spring-jdbc的方案如何,只是想说明两者其实有不同的侧重点的。
w412692660 2011-03-15
这个话说,真没什么发言权....很久没用HIbernate类似的orm的存储,业务比较复杂的时候orm表示不清,特别是业务主键的系统,通常数据库设计是按层来设计,多数走SAP表的设计路线,用ORM很难去使用,关联性太强;

再有就是,有时候设计表的时候,会有树形结构的方式,用对象实现复杂的递归查询;
复杂的业务,有时候很变态,要多层次树+加正反查...如果用ORM,消耗量太大...

至于,封装VO,就是个传递方式,这样其实和HIbernate,岂非一样,人家也支持反调接口;
说实话,没什么好建议,主要还是看项目的业务....
期待下边


凤舞凰扬 2011-03-16
w412692660 写道
这个话说,真没什么发言权....很久没用HIbernate类似的orm的存储,业务比较复杂的时候orm表示不清,特别是业务主键的系统,通常数据库设计是按层来设计,多数走SAP表的设计路线,用ORM很难去使用,关联性太强;

再有就是,有时候设计表的时候,会有树形结构的方式,用对象实现复杂的递归查询;
复杂的业务,有时候很变态,要多层次树+加正反查...如果用ORM,消耗量太大...

至于,封装VO,就是个传递方式,这样其实和HIbernate,岂非一样,人家也支持反调接口;
说实话,没什么好建议,主要还是看项目的业务....
期待下边


   呵呵,用ORM去解决查询问题,本来就是误解和误区。
skzr.org 2011-03-16
orm我觉得可用可不用,呵呵结合起来不就可以拉
BigBlue 2011-03-22
miaofm 写道
个人体会在项目中这些对象查询语言,有些鸡肋。整个就是就是sql和对象的结合体,既然不能做到完全对象化,干脆就不提供对象查询语言。

个人认为持久层应该是jpa的标注实现(增、删、改)和spring——jdbc的查询相结合。不用提供什么对象查询语言,你要查复杂的查询语句,就得自己写原始的sql,再封装为vo对象。

以上为个人体会,希望大家踊跃发表~~,谢谢!


1、和普遍的观点不一样,我认为无论是JPQL还是SQL,大多数情况下都是业务逻辑的一部分,应该放在领域模型里.试想这样一个场景:合计某个订单子项的金额合计。有两种做法:
   1)取出该订单的所有子项,循环累计其金额;
   2)发送一个SQL语句,得出其金额;
   前者放在领域层应该没有什么异议,后者实现同样的功能,理应也放在领域层中;

2、我不知到楼主说的JPQL之类的不能完全对象化是什么意思,难道你用JPQL查询出来的不是对象?除非你要把JPQL当作SQL来用。其实你看一下目前存在的各种各样的对象查询语言,大多长相和JPQL差不多。JPQL长相也确实和SQL很相近,但是其中的理念是不一样的。我经常听到同事说复杂的JPQL如何如何,其实,在领域层,你的JPQL不会复杂到哪里,你有导航可用,除非你要做复杂的报表统计,那个,另当别论了。

3、如果楼主只要VO,那么也别搞什么OO了,面向过程可能更合适。当然,我从来不认为面向过程是贬义词,我很敬畏。

凤舞凰扬 2011-03-31
BigBlue 写道
miaofm 写道
个人体会在项目中这些对象查询语言,有些鸡肋。整个就是就是sql和对象的结合体,既然不能做到完全对象化,干脆就不提供对象查询语言。

个人认为持久层应该是jpa的标注实现(增、删、改)和spring——jdbc的查询相结合。不用提供什么对象查询语言,你要查复杂的查询语句,就得自己写原始的sql,再封装为vo对象。

以上为个人体会,希望大家踊跃发表~~,谢谢!


1、和普遍的观点不一样,我认为无论是JPQL还是SQL,大多数情况下都是业务逻辑的一部分,应该放在领域模型里.试想这样一个场景:合计某个订单子项的金额合计。有两种做法:
   1)取出该订单的所有子项,循环累计其金额;
   2)发送一个SQL语句,得出其金额;
   前者放在领域层应该没有什么异议,后者实现同样的功能,理应也放在领域层中;

2、我不知到楼主说的JPQL之类的不能完全对象化是什么意思,难道你用JPQL查询出来的不是对象?除非你要把JPQL当作SQL来用。其实你看一下目前存在的各种各样的对象查询语言,大多长相和JPQL差不多。JPQL长相也确实和SQL很相近,但是其中的理念是不一样的。我经常听到同事说复杂的JPQL如何如何,其实,在领域层,你的JPQL不会复杂到哪里,你有导航可用,除非你要做复杂的报表统计,那个,另当别论了。

3、如果楼主只要VO,那么也别搞什么OO了,面向过程可能更合适。当然,我从来不认为面向过程是贬义词,我很敬畏。


   一般来说,QL是比较强大的,但是这也容易让人走进另一个循环误区,使用QL来构建表单查询,那么JPQL与基本SQL的区别除了返回的是对象而不是结果集,还有其他更多的区别么?
    同时对象QL一个最大的问题就是必须保证对象在进行了关联映射的情况下才可以使用。而许多人为了图方便使用QL或者对象查询,结果做成了超级复杂的对象关系映射,完全违背了专家职责原则。
   其实在大多数场景下,基于表单的查询结构都是简单的,或者说层次是清晰的。从面向对象的角度应该是封装构建查询框架,实现JPQL,HQL或者其他ORM以及SQL的映射查询。通过查询对象和注解的方式,完全可以实现并适应大多数场景。
   至于那些复杂的查询,如报表、统计、复杂关联,还是交给SQL吧。
BigBlue 2011-04-14
凤舞凰扬 写道
BigBlue 写道
miaofm 写道
个人体会在项目中这些对象查询语言,有些鸡肋。整个就是就是sql和对象的结合体,既然不能做到完全对象化,干脆就不提供对象查询语言。

个人认为持久层应该是jpa的标注实现(增、删、改)和spring——jdbc的查询相结合。不用提供什么对象查询语言,你要查复杂的查询语句,就得自己写原始的sql,再封装为vo对象。

以上为个人体会,希望大家踊跃发表~~,谢谢!


1、和普遍的观点不一样,我认为无论是JPQL还是SQL,大多数情况下都是业务逻辑的一部分,应该放在领域模型里.试想这样一个场景:合计某个订单子项的金额合计。有两种做法:
   1)取出该订单的所有子项,循环累计其金额;
   2)发送一个SQL语句,得出其金额;
   前者放在领域层应该没有什么异议,后者实现同样的功能,理应也放在领域层中;

2、我不知到楼主说的JPQL之类的不能完全对象化是什么意思,难道你用JPQL查询出来的不是对象?除非你要把JPQL当作SQL来用。其实你看一下目前存在的各种各样的对象查询语言,大多长相和JPQL差不多。JPQL长相也确实和SQL很相近,但是其中的理念是不一样的。我经常听到同事说复杂的JPQL如何如何,其实,在领域层,你的JPQL不会复杂到哪里,你有导航可用,除非你要做复杂的报表统计,那个,另当别论了。

3、如果楼主只要VO,那么也别搞什么OO了,面向过程可能更合适。当然,我从来不认为面向过程是贬义词,我很敬畏。


   一般来说,QL是比较强大的,但是这也容易让人走进另一个循环误区,使用QL来构建表单查询,那么JPQL与基本SQL的区别除了返回的是对象而不是结果集,还有其他更多的区别么?
    同时对象QL一个最大的问题就是必须保证对象在进行了关联映射的情况下才可以使用。而许多人为了图方便使用QL或者对象查询,结果做成了超级复杂的对象关系映射,完全违背了专家职责原则。
   其实在大多数场景下,基于表单的查询结构都是简单的,或者说层次是清晰的。从面向对象的角度应该是封装构建查询框架,实现JPQL,HQL或者其他ORM以及SQL的映射查询。通过查询对象和注解的方式,完全可以实现并适应大多数场景。
   至于那些复杂的查询,如报表、统计、复杂关联,还是交给SQL吧。


1、表面来看,JPQL与基本SQL的却别确实是数据集和对象这点差异,但本质上,用JPQL时你应该从对象的角度思考问题。不知道楼主抱怨JPQL不能做到对象化是什么意思,那么则样才是完全达到对象化呢?

2、导航是OO的一个特色,oo的时候别老想着Table怎么样,否则要出问题。我承认很多巨大的对象关系网的设计,这是用ood的一个挑战,必须要进行聚合的划分,必须要对关系进行一个取舍。导航关系是方便,但是不能为了方便而滥用。
   不知道楼主的专家职责是什么,是不是只单一职责的意思。我认为关系导航和这个没有关系。

3、封装JPQL?没看到有什么好处,也没有看到有什么好的解决方案。用一下JPA2提供的CriteriaQuery你就知道离了JPQL有多痛苦了。当然,要说没有好的解决方案也不完全,.NET 的Linq就比较完美,当然按楼主的标准,也是SQL的变体,不符合楼主的标准。

其实JPQL、SQL之类就是数据查询的DSL,发挥好一个事物的特点,需要一点智慧。
javamonkey 2011-05-06
查询还是sql好啊,一个O/R mapping 只提供轻量级的增,删,改,而不提供JPQL查询,我觉得是对性能和开发最好的。hibernate 做的太多了,非常不好用
凤舞凰扬 2011-05-10
BigBlue 写道

1、表面来看,JPQL与基本SQL的却别确实是数据集和对象这点差异,但本质上,用JPQL时你应该从对象的角度思考问题。不知道楼主抱怨JPQL不能做到对象化是什么意思,那么则样才是完全达到对象化呢?

2、导航是OO的一个特色,oo的时候别老想着Table怎么样,否则要出问题。我承认很多巨大的对象关系网的设计,这是用ood的一个挑战,必须要进行聚合的划分,必须要对关系进行一个取舍。导航关系是方便,但是不能为了方便而滥用。
   不知道楼主的专家职责是什么,是不是只单一职责的意思。我认为关系导航和这个没有关系。

3、封装JPQL?没看到有什么好处,也没有看到有什么好的解决方案。用一下JPA2提供的CriteriaQuery你就知道离了JPQL有多痛苦了。当然,要说没有好的解决方案也不完全,.NET 的Linq就比较完美,当然按楼主的标准,也是SQL的变体,不符合楼主的标准。

其实JPQL、SQL之类就是数据查询的DSL,发挥好一个事物的特点,需要一点智慧。

1. 说JPQL是从对象角度思考问题那完全就是扯淡了。面向对象从来没有QL这样的产物。JPQL的诞生完全是hibernate的HQL以及EJB实体Bean的EJBQL的一个衍生物罢了。QL诞生的根本原因就是从对象到关系的转换有时过于复杂。
2. 表达有误,是单一职责原则(本来是想说专家职责模式,但实质用在这里也不妥),谢谢指正。另外你想说的关系导航是关系映射吧?(ORM=Object Relationship Mapping,为啥会翻译成导航)你这里的说就是最大的一个问题了。实体模型也好,对象也模型也好,都是从概念模型本身转换的。完全不加思考通过对象构造表是最为愚蠢的做法。(这我就不批判你了,那些DBA童鞋会好好指导你的。)
3. 之所以进行封装QL就是为了让使用者更加通过面向对象的做法,比如hibernate的criteria,比如eclipselink中的query和expression.诚然,它们本来就不是解决所有查询问题的(但是可以解决90%以上的实体查询,你以为JPQL又有多强大?),真正复杂的非实体查询还是需要通过SQL的。
Global site tag (gtag.js) - Google Analytics