很久没有写文章了。
一直很忙，不是很有时间整理。
今天主要是来吐槽下那些设计很复杂的ORM的。
项目做的越多，越觉得ORM这个东西设计的太复杂实在是没什么意义。
比较推崇Dapper这样比较简单，效率比较给力的是ORM。
他其实什么都没做，只是把数据库的字段映射到对象的字段上，我觉得就这一个功能就OK了。
其他的功能对ORM来说基本上都是没什么用的。
待我慢慢道来！
一行只写一句话，是因为写C#代码习惯了，不是诗， 不要误会！
你说你的ORM支持全数据库。
啊哈，一般来说项目开始的时候数据库就已经选好型了。
只要你不是非常二逼或傻逼，选一些非常不入流，而且能力不是很强的数据库。
后面基本上是不会更换数据库的。
所以，为毛要支持啊。
在通用和性能之间，有一条沟，你要么站在沟左边，要么在沟右边。
站中间，哈哈，掉下去了。
你说你开始的没想到后面会有这么大的数据。
啊哈，你的架构师不给力么！
好，不是架构师的问题。
穷逼的，牛逼的MYSQL。
苦逼的，牛逼的MSSQL。
二逼的，牛逼的ORACLE。
傻逼的，牛逼的DB2。
大家一开始都是在考虑当前的需求。
并且稍稍的考虑的下未来几年的可能，或者没有考虑。
所以不能怪架构师，谁让甲方刚开始只给那么点钱。
好了，时间越来越久，数据库越来越慢。
肿么办？
升级数据库哈！
这不，你看还是有换数据库的需求的吧。
啊哈，怎么说呢？
总觉得换一种数据库就能解决问题？
世界上著名的数据库就那几种！
在一些特定的领域
ORACLE比MSSQL牛逼多少？
MSSQL比MYSQL牛逼多少？
牛逼不了多少的哈
没见上边么，每一种数据库都有牛逼的人在用么
你觉得你的数据库不行！
你调优了么？你优化业务了么？你还在用奔腾时代的机器来挑战这大数据时代么？
所以，换数据库是最最坏的打算。
而且你就算想换，现在的ORM也解决不了100%的问题啊。
数据迁徙，要专业工具！数据库管理，要专业人员！
所以你想用一套东西来解决所有问题。
上帝尚不能造一块自己搬不起的石头，何况是你！
你说用了ORM,妈妈再也不用担心的我SQL了！
啊哈，怎么吐槽你呢？
好的开发人员有四个技术基本功，知道么！
开发语言，SQL，抽象能力和自嘲！
不会任何一样，你都不是一个好的开发。
会拿开发语言写函数，会自定义对象，会拿语言表述一套完整的业务流程。
不错！很不错！
但是你还差三样！
你起码要会写函数吧！知道怎么拿SQL自定义类型吧（对不起，主流数据库都支持的哈）！会用存储过程来表述一套完整的流程吧！
但是你差两样！
你说你已经写了一套ORM可以通吃所有数据库啦！
呵呵，不错！来，学着星爷的腔调来一句，“其实我是一个程序员”！
哦也，你功德圆满，随你师父和大师兄，三师兄以及小白马回大唐去吧！
什么！
你说不要把业务放到数据库里面，换数据库不方便！
骚年，从头看看。
好，你已经看过了，但是你还是觉得放到数据库里不放心，你还是可能换数据库！
各种主流数据库的表主流的字段类型基本可以通用哈。
各种主流数据库的函数和存储过程的调用都差不多哈。
各种主流数据库的你有的基本大家都有哈。
只要不使用太特殊的东西，换个库神马的，小case啦。
你说你用了！
你说你用了ORACLE的包，Java Source！你想换！
你说你用了MSSQL的表变量，C# UDT,花了好几千大洋装上了R2!你想换！
你说你用了MYSQL的枚举，对InnoDB疼爱有加！但是你想换！
.......
少年，为什么要放弃治疗！
都这样了，都沧海桑田了，你还是好好珍惜你们的感情吧。
换啥！换一种思维来解决问题吧，坑挖的越来越深的时候，就该想想是不是改往宽挖挖了！
就算非得换数据库，你真的以为，自定义的那套别扭的语法能为你新的数据库带来很好的性能么？
说我了解的，只说最简单的，而且通用的语法层面！
CTE这么好用的东西，你来，用ORM生成一条试试看。
MERGE这么好用的东西，你来，用ORM生成一条试试看。
SQL BLOCK这么好用的东西，你来，用ORM生成一条试试看。
（注：SQL BLOCK是ORACLE的叫法，MSSQL原生支持所以没有太V587的名字）
为什么非要各种数据库的方言上做痛苦的挣扎？
你确实练就了一身无敌的抽象能力，你确实碉堡了！
但是，呵呵，别忘了那句，“我是程序员，你叫我序员就好了”，生亦何欢死亦何苦哈，何必非要和自己过不去呢，是不！
你说你是处女座的，而且你还是个苦逼的后端程序员！
你是说你见不了后台代码里，被SQL玷污的满目疮痍的开发代码！
啊哈，SQLSHOP听过么，把SQL全部放到外置文件里进行统一管理，所有的查询都是按照绑定变量的方式进行。
从不拼SQL，从不把SQL写到代码里，复杂的业务写成存储过程或函数。
SQLSHOP让你的代码一尘不染。
SQLSHOP让你担心的注入问题，执行计划问题轻松解决。
SQLSHOP让你在写代码的岁月里幸福的像花儿一样。
那什么地方有SQLSHOP呢？
啊哈，刚好本仙身上带了一包，暂给元帅尝尝鲜，涉及一些不太方便的代码，请自行脑补。
public class SQL { private Dictionary<int,string> Sqls{get; set;} private Dictionary<string,object> Parameters{get; set;} public SQL(Dictionary<int,string> sqls) { if (sqls==null||sqls.Count==0)throw new NotSupportedException("sql can't empty"); this.Sqls=sqls; Parameters=new Dictionary<string,object>(); } public void AsyncExecute<T>(Action<Exception> error,Action<T> back) { //...查询数据库返回数据并映射到对象上 } public void Add(string pname,object value) { Parameters.Add(pname,value); } public void Clear() { Parameters.Clear(); } }
public class SQLPath:DynamicObject { private StringBuilder builder=new StringBuilder(); public override bool TryGetMember(GetMemberBinder binder, out object result) { var name = binder.Name; builder.Append('\'); builder.Append(name); result=this; return true; } private SQLPath(){} public static dynamic RootPath { get {return new SQLPath();} } public SQL ToSQL() { return SQLShop.ReadSQL(this); } public string Path { get{ return builder.ToString(); } } }
public static class SQLShop { public static SQL ReadSQL(SQLPath sqlpath) { var path=sqlpath.Path; Dictionary<int,string> sqls=new Dictionary<int,string>(); //...按照文件组织或xml文件或者其他方式来读取这种查询下的全部sql，并做缓存 //...获取全部SQL，并取出每个SQL的SQL参数的生成hash值存入到sqls的键种 sqls.Add(-1581397123,"SELECT USER_NAME ,USER_ID FROM T_BASE_USERS T WHERE T.USER_NAME LIKE :user_name"); sqls.Add(24307103,"SELECT USER_NAME ,USER_ID FROM T_BASE_USERS T WHERE T.USER_NAME LIKE :user_name and T.ADDRESS LIKE :address"); return new SQL(sqls); } }
void Main() { var root=SQLPath.RootPath.UserManager.UserPower.QueryUser;//用户管理-》权限管理-》查询用户 var sql=(root as SQLPath).ToSQL(); sql.Add("user_name","%王"); sql.AsyncExecute<User>( ex=> { //发生异常 Console.WriteLine(ex); }, User=> { //取到正确数据 }); sql.Clear(); sql.Add("user_name","王__"); sql.Add("address","%西安%"); sql.AsyncExecute<User>( ex=> { //发生异常 Console.WriteLine(ex); }, User=> { //取到正确数据 }); }
（SQLSHOP的思想不是做一个ORM，而是做一个SQL的管理器，统一管理这些SQL，而不是凌乱的散落在各个class文件里面。）
你说我总算发现了，你对我们这些功能齐全的ORM有偏见！
啊哈，你说对了！
不过我的偏见是有理由的哈！
关系本来就是该数据库来处理，RDBMS的第一个R就是指关系，这个关系是说数据之间的数据关系。
OO语言里面也有关系，不过是对象关系，虽然可以将数据关系按照某个原则转换到对象上！
但是为了按照数据关系来组织数据对象总感觉不是那么美好！
NH已经不是那么火热了！
LINQ TO SQL也已经在慢慢消失。
EF虽然活着，但只是活在很多小的项目，或者懒的开发人员那里。
要想一套很好的ORM，想想NOSQL吧！
只需要单表映射，不要再把复杂的关系组织到OO上了。
就算某天觉得关系型数据库不给力了，想换NOSQL。
噢耶，程序里面全是单表操作，so easy！
珍爱生命，远离复杂的ORM！
那怎么判断一个ORM是否复杂呢？
1.全部使用对象的方式来操作数据库。（按理说，所有的开发人员应该都是见不到物理表的，所见的只能是视图，函数，或存储过程）
2.由机器自动生成SQL并执行。（EF生成的SQL好么，你用一张C#的内存表关联一张数据库的一张表试试看，那长长的SQL，那淡淡的忧伤）
3.包含复杂的查询语法，企图用一套自己的语法来通吃所有数据库。（你明白的，通吃有用？学习啥语法都不如学好SQL，数据库就那几种，SQL都差不多的）
4.不承认我上边说的的，还执迷不悔的，就当我啥都没说，我没有在说你哈!