ORM 思考3 查询


ORM 思考3 查询



前言

一般查询不是任意的,而是和业务相关的,也就是说会在产品里面写死的。例如查询日期为2000年的订单,这个查询条件是在程序里面写死存在的。

不可能出现,今天这样查,明天那样查。如果这样,程序员会崩溃的。

所以嘛,不要把查询复杂化,写很多的规范。即使最笨的方法,只要好用,放在那里就行了。如果做到toplink那样的.equal()/ .great()才能满足复杂查询,太不必要了。hibernate的查询是很有意思的。

我的idea

最后说说我的查询,查询发出者来自对象本身,并且作为方法写死在里面。比如:

Person
{
 Email GetEmail(
string  type)
 { 
    
// 寻找满足type要求的email
 }
}

这样调用的时候,效果就是:

Email mail  =  person.GetEmail( " China " );

非常的自然和符现有的面向对象操作。有多少种查询,就写多少个方法在person里面。

对于复杂的查询,一定是在xxx条件下的某对象查询。这个xxx条件一定与对象存在外键关联。比如上文person和email就存在外键关联。

因此如果对于多级的复杂嵌套查询,实际上好像个马尔可夫链的情况,是无前状态的。比如在person情况下查email,是不需要知道怎么查到这个person的,只需要知道当前person是什么状态。

根据这个条件,可以把复杂的嵌套查询分解在每个对象里面。
查询 来自“pixysoft”的person,属于“机器制造”的email,是“china”的address的内容。

db.Get < person > ( " pixysoft " ).GetEmail( " 机器制造 " ).GetAddress(“china”)..

没有必要写很长的复杂查询语句。

转载于:https://www.cnblogs.com/zc22/archive/2007/10/26/938156.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值