现在的.net or构架，大家认同的各种大大小小，ef,subsonic,nhibernate，甚至小一些的petapoco这种，但用过的人我想他们考虑的是比较多。

小一些的Petapoco也有几千行的代码。

而有一些或是配置困难，或是脱离不了一些sql,

而我一直在寻找一种更简便的方法简化自己的开发，使自己更容易的操作数据。

由于最近在用mysql,而mysql使用myism引擎和innodb引擎时，由于Innodb引擎支持更广泛些，事务等，虽然在字符索引上可能较myism差些，不过用是必须可以的。

自己就着手写了一个小型的or类型。

具体的实现思想是 Knock out converter.

上一篇中，我个人认为软件OO的思想在于最小化输入配置，而最优化OO方法的精简与重构。

大家都知道在开发中，接收到数据往往是string类型的，若用webservice,wcf,remoting等远端接口，远程调用的方法自然直接是实体，但在与数据库的协作时往往需要将MODEL的类型在parameter 中指定为数据库对应的类型，.net framework其实是有一个infertype的，也就是在操作数据的时候，不指定数据库类型，只是添加prametername 与value,那么，在操作库时，就可以直接进行操作了，而将数据类型的验证放到了库的操作上下文中，也就省掉了程序上类型上的麻烦，当然这是一个取巧的方法，但是这种方法却是最简单明了和易于操作的。

这也是我自己写的or工具中的核心部分。

思想仍旧是 “约定大于配置”，假定表中默认含有id主键，自动增长，单表名与实体名小写相对，那么，我们就可以根据这些约定构造出相应的库表操作语句。

而对于sql注入方面，大家都知道parameter往往是对参数进行重新编码 可以一定程度上防注入，那么，这样我们也可以构造出对应的SQLPARAMETER，通过工厂和抽象的sqlhelper，将具体的sqlhelper注入到操作类中实现各种库的统一操作。这样就可以实现一个单表的Orm.

而对于字符长度等等可以按ef,subsonic的实现，添加特性，限定字符长度，设定主键列，如果没有keycolumn,则采用默认约定用id列

我个人认为，若是在实体中添加上字符长度，数据类型和regular expression等的验证，就可以实体直接的sql直接生成，那么这样就可以实现code first，但 db first往往是我们更多用的方式，所以，扩展上可以那么实现，而且原理就是这个了，orm也基本这么个思想。