ORM的思考
单刀直入
首先我很怀疑ORM中查询的复杂程度是否必要。当然LINQ是个很强大的东西，但是面对80%的简单操作，为什么不只是用20%的努力呢？
我看了NBear, toplink, hibernate,他们都在select上面下了很大的功夫，在xx to xx mapping上面提供了很多的映射模型。但是这些必要吗？
我的IDEA --- MAPPING
我的想法很简单，既然使用了ORM，用户就根本不要考虑到底对象怎么去映射到了数据库，数据库的字段怎么去读取。管他这么多。就像一个磁盘被配置成了RAID 10的时候，你会考虑某条数据放在哪里吗？
所以，即使ORM把数据库表空间管理的乱七八糟，表明字段名、表约束、外键都看不懂了，但是只要面对用户的时候，ORM能够正确的读取，那么就行了。
根据这点，我设计ORM的时候，很多mapping使用了自己规定的方式，连表名我都自己去规定了，不让用户操心。用户只要乖乖的去处理对象就好了。
我的IDEA --- SELECT
再说回查询，看见oracle的toplink里面session超级长的查询，再看看nbear，也是复杂的看不懂。
我现在在内存中处理对象的时候，一般的查询都很简单.
schema.GetTable(string tablename)
就这样，哪来什么又这个嵌套，又那个groupby。这些是关系数据库的功能，为什么要用在对象数据库？不解。
如果真的用到了复杂的查询，即使没有数据库，我也需要写代码，例如找一个数据库里面是否存在循环外键，我相信查询功能再强大也很难满足我这个需求。
所以ORM里面给用户的查询要很简单，可能根据几个 == 就能够找到了。但是面对复杂的查询操作，要么设计一套面向对象的存储过程，要么写代码逻辑。别把查询复杂化。
我的IDEA --- 模型建立
最后我帖一个我设计的ORM模型：
ObjectProxy schema = new ObjectProxy();
schema = schema.Select("TEST");
Console.Write(schema.Get("TABLE").Select("ITM_ITEM").Get("COLUMN").Select("ITEMCODE").Get("COLUMNNAME").Value);
schema = schema.Select("TEST");
Console.Write(schema.Get("TABLE").Select("ITM_ITEM").Get("COLUMN").Select("ITEMCODE").Get("COLUMNNAME").Value);
解释一下：我这个对象是数据库的元数据对象。操作结果是数据库TEST中表ITM_ITEM的字段ITEMCODE的字段名是什么，当然，返回值就是ITEMCODE
至少，如果不使用数据库，单纯的内存对象操作，代码形式都是接近的。
schema.GetTable("ITM_ITEM").GetColumn("ITEMCODE").ColumnName ( of course = ITEMCODE)
至少，使用了ORM，感觉和没用一样。
我觉得这样才算是可用的。
后记
我觉得只要相互取笑、鄙视，才能激发人的斗志，这个世界才会进步。所以请取笑我。但是也请在取笑我的同时，给我一个原因、到底、或者更好的解决方案。
问题汇总
Question 1:
schema.Get("TABLE").Select("ITM_ITEM").Get("COLUMN").Select("ITEMCODE").Get("COLUMNNAME").Value
你有没有发现很多组件的想把"ITM_ITEM"这样的String编写方式去了是出于什么原因吗?
你认为你这相比直接SQL省事方便?
不信自己可以写这样一个SQL来对比一下,当然SQL还需要加上Connection等东本(但那些都是封装上的问题)
Context.Execute("select * from customer");
Answer 1:
这个问题在我没有花几天时间去看orm的时候也怀疑着。
但是我看到了hibernate里面的理论之后，突然想开了点。感觉orm导致的是个思路的转变。
例如我们有个对象
class 订单
{
string 订单编号
List<订单子表> 订单子表1
}
{
string 订单编号
List<订单子表> 订单子表1
}
class 订单子表
{
string 子表编号
}
{
string 子表编号
}
在面向对象中，这种关系经常看见。但是怎么保存在数据库呢？我没有接触orm之前，使用了序列化，保存为xml了。但是之后，我有所领悟。
顺便说一下我这个模型，是个代理。objectproxy。不是最终用户使用的。但是用户自定义的类会被映射到这个模型。
思路和.net里面的消息机制一样,ImessageSink。
Question 2:
引用楼主“再看看nbear，也是复杂的看不懂。”
nbear很复杂吗？不说别的，他的强类型查询我就认为是最自然，最舒服的方式。
说句实话，你的Noebe我看过，还真的不如直接使用Sql。
Answer 2:谢谢你看过。不过你看到了只是noebe查询部分和sql一致。非常正确，我不想用自以为是的框架去取代强大的sql。框架再强大，也不能取代sql。所以在查询部分，我暴露了sql接口。
但是我把剩下的都做的很简单，比如Insert, Update, Delete。相信这不是几个sql能够解决的。