ORM 思考3 查询
前言
一般查询不是任意的,而是和业务相关的,也就是说会在产品里面写死的。例如查询日期为2000年的订单,这个查询条件是在程序里面写死存在的。
不可能出现,今天这样查,明天那样查。如果这样,程序员会崩溃的。
所以嘛,不要把查询复杂化,写很多的规范。即使最笨的方法,只要好用,放在那里就行了。如果做到toplink那样的.equal()/ .great()才能满足复杂查询,太不必要了。hibernate的查询是很有意思的。
我的idea
最后说说我的查询,查询发出者来自对象本身,并且作为方法写死在里面。比如:
Person
{
Email GetEmail(string type)
{
//寻找满足type要求的email
}
}
{
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”)..
没有必要写很长的复杂查询语句。