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”)..

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