很久没有写文章了。

一直很忙,不是很有时间整理。

今天主要是来吐槽下那些设计很复杂的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();
   }
}
SQL class

相关文章:

  • 2021-05-25
  • 2022-12-23
  • 2021-09-13
  • 2022-12-23
  • 2022-12-23
  • 2021-08-24
  • 2021-11-17
  • 2021-09-19
猜你喜欢
  • 2021-06-26
  • 2021-04-15
  • 2021-09-09
  • 2021-10-22
  • 2021-07-22
相关资源
相似解决方案