ORM实现有反射、范型、代码生成等几种常见方式，或者单用，或者混合。

c#的范型非常强大，应用于ORM时，可能有些特性显得更重要。

一开始实现时，我尝试写一下代码做为ORM基类

namespace Coat
{
    public class ORMBase<T> where T : class
    {
    	...
        public bool Update()
        {
            using (var conn = OpenConnection())
            {
                //Beblow compile error, because conn.Update<T> expect parameter to be T
                //i.e. the sub-class, but "this" is parent class.
                return conn.Update<T>(this);
            }
        }
    }
}

// 子类生成的代码类似：
	public class User: ORMBase<User> {
	...
	}

意图是在基类中实现ActiveRecord对象增删改查等通用方法，相比起在具体子类中使用代码生成实现相应的代码会更简洁些。并且，编辑一个实际类型，总比编辑模板方便。

做为一个玩了两年没有范型的语言（GO）的人，我会觉得 c# class User: ORMBase<User> {这样的类型声明很强大。

User类型继承于ORMBase，而类型ORMBase正是使用User类型做为范型参数。这没有循环依赖？

这样ORMBase中，便可以利用范型T做各种编程。

上面代码是卡在了conn.Update<T>(this);这句调用。

因为dapper的Update方法签名类似Update<T>(T entityToUpdate)，我在ORMBase中写的this是父类，也就是ORMBase；而传进去给Update的类型参数T，则是子类，比方说User。

编译器直接就报错了。

ORMBase跟T是两个不同的类型，无法直接转换，写conn.Update<T>((T)this);编译器也是报错。

有同事建议修改ORMBase的Update签名，变成public bool Update(T obj)，然后把传obj而不是this给dapper。

这样虽然可以解决编译问题，但会让应用调用时变麻烦；还不如直接把Update方法搬去子类里面生成出来，但还是不漂亮。

研究了一番范型约束，结果找到更漂亮的方式。

ORMBase跟T无法相互转换是因为编译器不知道他们之间的继承关系，把他们的继承关系写到范型约束中便可以转换了。

public class RecordBase<T> where T : RecordBase<T>

这样声明约束T必须是RecordBase<T>的子类；Update方法改为：

return conn.Update<T>((T)this);

便可以顺利编译了。

虽然可以编译，但这里是把父类转换为子类，何以可以顺利编译，我其实还木有搞明白细节。

有朋友知道，还望告知。

谢谢。