为什么不推崇复杂的ORM_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 为什么不推崇复杂的ORM

为什么不推崇复杂的ORM

 2013/10/3 12:40:25  Code Monk  博客园  我要评论(0)
  • 摘要:上一篇文章写完,回复的人很多,有的说的很中肯,有的貌似只是看到文章的标题就进来写评论的!还有人问为什么我要屏蔽掉【反对】按钮,因为谁写文章都是为了分享,都在说出自己的心得体会。不过由于大家遇到的项目,做的东西,见过技术各有差异,很难让每个人都向一种意见靠拢。所以你可以不喜欢,但是请不要作恶!评论中*深海,lindping说的是通用的ORM可以为通用产品带来部署的便利!dax.net,深蓝医生,路过秋天说的是ORM一个很关键的作用就是可以加快开发速度!还有些属于性能控,对SQL比较推崇
  • 标签:什么 为什么

      上一篇文章写完,回复的人很多,有的说的很中肯,有的貌似只是看到文章的标题就进来写评论的!还有人问为什么我要屏蔽掉【反对】按钮,因为谁写文章都是为了分享,都在说出自己的心得体会。不过由于大家遇到的项目,做的东西,见过技术各有差异,很难让每个人都向一种意见靠拢。所以你可以不喜欢,但是请不要作恶!

      评论中*深海, lindping说的是通用的ORM可以为通用产品带来部署的便利!dax.net,深蓝医生,路过秋天说的是ORM一个很关键的作用就是可以加快开发速度!还有些属于性能控,对SQL比较推崇。还有些没有明白表达的意图,语文是音乐老师教的!实在抱歉!

     先说下部署这个问题,如果是做通用产品的话,考虑到各种数据库的兼容确实能带来很多好处。这一点我很认同,不过从业开始但现在,接触过的项目基本上都是属于定制类的,所以这一点没能感同身受。有过一次,不过不是换数据库这么简单,而是换整个部署方案,从WINDOW平台换到LINUX上,数据库从MSSQL换成ORACLE。没用ORM,用的SQLSHOP+存储过程的方式来做的系统,前后一个星期全部完工。因为SQLSHOP的SQL都是可以人工干涉的,存储过程这一类的调用也是放在SQLSHOP里面,所以我们基本上没有动一行代码,都是通过机器生产和人工的方式来修改存在XML里面的SQL,效果还可以。也是因为这次的经历,我才发现原来MSSQL和ORACLE其实差不了多少,存储过程,SQL函数,调用的语法,性能等等.Mono加JEXUS,有时比IIS还给力。

      开发效率是评论中比较让我纠结的。因为我不是说我不用ORM,而是我觉得ORM设计的太复杂,没有什么太大的意义(原文第四句哈)!

      主流的数据库,其增【INSERT INTO . (.,.)VALUES(.,.)】,删【DELETE FROM . WHERE ...】,改【UPDATE . SET .=. WHERE .=.】的语法都一样,这部分可以抽象,做出一个支持CUD(没有R)的系统。

      但是查询就不是那么简单了,人们对数据的关注点不一样,所以需要的查询语句就不相同。不是所有主流数据库都有一个相同的查询系统,所以这一部分很难抽象。

      所以没有一套ORM能很完美的处理了查询问题。

      1.语法上,没法做到比SQL更简洁。

      2.语义上,各库SQL方言的差异很大。你需要为每个主流数据库写一套不同的SQL方言系统,你需要了解各种库SQL的特点。

      3.语用上,你需要动态生成符合当前情景的SQL。比如你做分页,每种库纯SQL的分页方言就有很多,每种分页在不同的分页情景下效率是不同的,最优的情况是你可以动态去判断情景。

      上述三点,不说第三点。前两个弄得很好的ORM,开源的NHibernate没有做到,微软自己的EF没有做到,商用的LightSpeed也没有做到。目前的ORM都是在1和2上下功夫。3很难,而且对需求如此苛刻的也不会使用ORM了。所以,我倒是觉得与其活生生的坑在这三点上,倒不如从以下几个方面好好考虑一下,数据库支持,功能支持,语法支持,映射支持等。比如:

       1.考虑下NOSQL吧,可以做完整单表映射或NOSQL数据的对象映射。

             怎么支持RavenDB,STSdb,MongoDB,Cassandra等?

       2.考虑下DDD吧。功能齐全的CUD系统,能否很好的支持CQRS中C?

             怎样快速从数据库中映射出运行时对象?反射,EMIT,表达式

             怎么提高缓存的命中?支持Memcached,还是使用自己实现的?

       3.考虑下支持OO原生特性,因为需要拿ORM来表达业务流程,是站在OO的角度考虑问题而不是数据库。那么你的ORM就需要考虑一些数据库问题了。

            怎样为有继承关系的对象设计表?共享同一张表,还是分开,然后使用字段关联?

            怎样选择更新时的充血或贫血?充血和贫血都有优缺点,怎样选择?

            业务对象是可以用户实例化的还是只能由ORM实例化?用户实例化和ORM实例化各有各的好处,选择哪个?

            可否为对象及对象的属性添加拦截?能够知道系统中最热对象是哪个,最热属性是哪个,由此可以得出一些很有意思的信息在,怎么设计?

             ......

            这实在是太多了,不管是细节还是宏观上,都太多了。

       4.考虑下支持从数据库直接映射成XML或JSON吧,或把XML或JSON直接转换为SQL吧,虽然XML和JSON不是对象,但是越来越多的地方使用XML或JSON来做对象容器。

           

      说完查询SQL生成的复杂,再说业务逻辑的问题。把复杂逻辑放在代码,还是放在数据库里面。其实这个也很让人纠结。站在数据库的角度想,在离数据越近的地方处理数据越快,所以放在数据库里面吧。但是站在代码的角度考虑,各种对象组合在一个表达了一套完整的业务流程,用OO的方式去考虑这个流程远比使用数据库表结构去表达要好很多,所以放在代码里面吧!......评论中地狱门神的评论很直接,我也很想这么做。但是有时候,完全使用代码去完成一套业务流程是不靠谱的。使用存储过程的时候,一切都是在数据库中,少了从数据库表到运行时对象的转换,肯定会快很多。而且业务流程越复杂,这一点体现的越明显。如果你的系统中有个部分是和很多表关联的,比如权限模块,你用ADO.NET到OBJECT,再处理OBJECT,再使用OBJECT和ADO.NET获取新的OBJECT的这种串行化的方式处理业务流程,当表的关联到达一定程度的时候,那个速度是完完全全不能忍受的。这个时候就需要使用存储过程了。

    所以根据以往的经验,使用存储过程的地方主要是两点。

    1.如果有部分的业务变化比较频繁并且有一些性能要求,使用存储过程吧,这样在系统运行时就能轻松的修复一些问题

    2.如果一个流程关联的表比较多(多于3张以上的表),而且每个表的数据都超过1W,那么也用存储过程吧。

    如果对性能要求不高,表关联也不多,业务流程很简单,那就可以使用代码的方式来表达业务流程了。

 

    所以,想想吧!

    复杂查询SQL,就算是再复杂的ORM也玩不来的,与其如此,倒不如设计的简单易用些。

    不要再为ORM考虑怎么全部的CURD都是对象操作,怎么全部的查询SQL都是自动生成,怎么设计支持多表关联了。

    作为程序员,何必活的那么复杂,大道至简! 

发表评论
用户名: 匿名