Entity Framework,Velocity ,Azure OS 本质上是解决同一个问题 。
2008-11-13 10:46
218 查看
在我已经确定在Client端完全遵守Web 标准之后,要为我的Server端考虑一下前途了。面对那么多的技术方案,谁都希望选择一个更有前途的演进方案。
在看了微软的PDC的更多视频和自己的思考以后,我做出了下面的选择。
我的选择是跳过Entity Framework 1.0,拥抱Velocity ,对Azure OS持乐观态度。
我感觉这三个东西其实反映了同一个本质性问题。
那就是哪里才是数据的家,硬盘还是内存? 原来肯定是硬盘,而现在正在有向内存迁移的趋势,而这个趋势将带来软件架构的根本性变化和相应的技术演化。
下面是一些推导过程。
首先,对程序员来说,计算机可以抽象成3大块,硬盘,内存和CPU。这3个玩意各自有其它奇特的地方。
1,CPU速度最快,然而容量最小,数据一进就需要赶快出来。
2,内存速度较快,容量也比较大,但是有个致命的缺点,它需要加电。
3,硬盘速度最慢,容量最大,它有一个最大的优点,断电了数据也能保存。
于是聪明的数据很快就作出了决定,硬盘才是我的家,为了更好的管理硬盘上的数据,数据库技术产生了。整个数据库技术的发展史就是围绕解决硬盘这个瓶颈而演进的。简单的说,你在写C#的代码的时候,就是在操作内存里面的数据,写SQL就是在搞定硬盘。于是聪明人就希望能够用ORM 来屏蔽掉数据库。把搞定硬盘这个脏活交给系统去完成。然而这个几乎是不可能完成的任务(注意这里说的是几乎)。为什么呢?
1, 因为数据总是要回硬盘的,无论你在内存中如何变幻,只有回到硬盘才有了语义上的意义。单个的一个日期,一个单价,甚至一个对象没有太大意义,只有放到了表结构这个语境中,数据才获得了意义。这就是commit为什么这么重要的原因。通过数据库备份技术,我们就可以保留了一堆有意义的数据。
2,从内存到硬盘的映射必然是不完全的,有缺陷的,拓扑结构不同的东西是没有办法完美映射的。学过几何的都知道,一个3厘米的线段是可以完美的投射到一个5厘米的线段,然而没有办法投射到一个方块上。
另外EF并不认为内存是数据的家, 归根到底还是映射到硬盘,只是演化的一个分支。我选择跳开这一版,反正现在还没有投入很多。 提醒一点, 如果是企业系统, 比如一个ERP, EF也是一个可行的方案, SAP的EF模型已经完美地运行了十几年了。
关于Linq to Sql, 我选择继续使用, 原因如下:
1, linq to sql本身是一个很轻型的方案
2, linq to sql 转化为 老的Ado.net 也很容易。
3, 我是主要投资到数据库的(就是大量存储过程),所以对linq to sql 的依赖很小。
接下来就是Velocity了, 这是一个Cache方案,采用这个技术其实是一个理念上的转变。
他划清了硬盘和内存的界线。也就是说,我还是用我的T-SQL管理好我的数据库,如果要提高性能,就大大方方地把数据放到一个叫Cache 的地方。这个演变和WCF 的演变很相似。
从最初的RPC,到Remoting,都是希望能将一个远程过程或者对象封装成一个本地对象,到WCF就正式承认远程的就是远程,就是要用不同的逻辑去处理的。反而编程模型更加清晰,便于维护和演进了。
由于Velocity的开发人员很多原来都是开发Sql Server的,那么Velocity就会具有一些数据库的特性了。由于是一种演进中的技术,所以会有各种不成熟的地方。但是对我来说性能提升最有价值,所以我会尽量投资在这上面。随着Velocity的流行,Cache-based的开发模式也许会流行起来吧。
最后说一下Asure OS
这是一个划时代的新东西,但是对于一个每天都是写代码的程序员来说,其实只有一件事情,硬盘概念在编程模型里面彻底消失了,数据再也不用”Commit”了,数据库概念也没有了,T-Sql没有了。剩下的就只有对象了。
Asure OS 是一个完全重写的OS, 而且从设计之初就是一堆系统一起运行的,硬盘仍然存在,但是被操作系统彻底屏蔽了。你需要就是new 一个对象,然后那个对象就会永远存在,除非微软的数据中心遭受重大灾难。 其实数据在你不经常使用的时候,还是会被交换到硬盘里去的,但是这对你来说是完全透明的,和Windows的虚拟内存的概念有点象。但是为什么你会几乎感觉不到延迟呢?因为数据时散列到几十个,几百个硬盘上,所以速度就非常快。
于是无限的可能性就打开了,单链,双链,堆,队列,二叉数,集合,。。。。。爬虫,代理等等,只有想不到,没有做不到,你需要的只是一个new关键字,各种想都不敢想的复杂的程序将会象蝗虫一样涌现了,直到AI(人工智能)产生,人类失去存在的价值为止。
最后一句是玩笑,哈哈,欢迎大家批评指教。
在看了微软的PDC的更多视频和自己的思考以后,我做出了下面的选择。
我的选择是跳过Entity Framework 1.0,拥抱Velocity ,对Azure OS持乐观态度。
我感觉这三个东西其实反映了同一个本质性问题。
那就是哪里才是数据的家,硬盘还是内存? 原来肯定是硬盘,而现在正在有向内存迁移的趋势,而这个趋势将带来软件架构的根本性变化和相应的技术演化。
下面是一些推导过程。
首先,对程序员来说,计算机可以抽象成3大块,硬盘,内存和CPU。这3个玩意各自有其它奇特的地方。
1,CPU速度最快,然而容量最小,数据一进就需要赶快出来。
2,内存速度较快,容量也比较大,但是有个致命的缺点,它需要加电。
3,硬盘速度最慢,容量最大,它有一个最大的优点,断电了数据也能保存。
于是聪明的数据很快就作出了决定,硬盘才是我的家,为了更好的管理硬盘上的数据,数据库技术产生了。整个数据库技术的发展史就是围绕解决硬盘这个瓶颈而演进的。简单的说,你在写C#的代码的时候,就是在操作内存里面的数据,写SQL就是在搞定硬盘。于是聪明人就希望能够用ORM 来屏蔽掉数据库。把搞定硬盘这个脏活交给系统去完成。然而这个几乎是不可能完成的任务(注意这里说的是几乎)。为什么呢?
1, 因为数据总是要回硬盘的,无论你在内存中如何变幻,只有回到硬盘才有了语义上的意义。单个的一个日期,一个单价,甚至一个对象没有太大意义,只有放到了表结构这个语境中,数据才获得了意义。这就是commit为什么这么重要的原因。通过数据库备份技术,我们就可以保留了一堆有意义的数据。
2,从内存到硬盘的映射必然是不完全的,有缺陷的,拓扑结构不同的东西是没有办法完美映射的。学过几何的都知道,一个3厘米的线段是可以完美的投射到一个5厘米的线段,然而没有办法投射到一个方块上。
另外EF并不认为内存是数据的家, 归根到底还是映射到硬盘,只是演化的一个分支。我选择跳开这一版,反正现在还没有投入很多。 提醒一点, 如果是企业系统, 比如一个ERP, EF也是一个可行的方案, SAP的EF模型已经完美地运行了十几年了。
关于Linq to Sql, 我选择继续使用, 原因如下:
1, linq to sql本身是一个很轻型的方案
2, linq to sql 转化为 老的Ado.net 也很容易。
3, 我是主要投资到数据库的(就是大量存储过程),所以对linq to sql 的依赖很小。
接下来就是Velocity了, 这是一个Cache方案,采用这个技术其实是一个理念上的转变。
他划清了硬盘和内存的界线。也就是说,我还是用我的T-SQL管理好我的数据库,如果要提高性能,就大大方方地把数据放到一个叫Cache 的地方。这个演变和WCF 的演变很相似。
从最初的RPC,到Remoting,都是希望能将一个远程过程或者对象封装成一个本地对象,到WCF就正式承认远程的就是远程,就是要用不同的逻辑去处理的。反而编程模型更加清晰,便于维护和演进了。
由于Velocity的开发人员很多原来都是开发Sql Server的,那么Velocity就会具有一些数据库的特性了。由于是一种演进中的技术,所以会有各种不成熟的地方。但是对我来说性能提升最有价值,所以我会尽量投资在这上面。随着Velocity的流行,Cache-based的开发模式也许会流行起来吧。
最后说一下Asure OS
这是一个划时代的新东西,但是对于一个每天都是写代码的程序员来说,其实只有一件事情,硬盘概念在编程模型里面彻底消失了,数据再也不用”Commit”了,数据库概念也没有了,T-Sql没有了。剩下的就只有对象了。
Asure OS 是一个完全重写的OS, 而且从设计之初就是一堆系统一起运行的,硬盘仍然存在,但是被操作系统彻底屏蔽了。你需要就是new 一个对象,然后那个对象就会永远存在,除非微软的数据中心遭受重大灾难。 其实数据在你不经常使用的时候,还是会被交换到硬盘里去的,但是这对你来说是完全透明的,和Windows的虚拟内存的概念有点象。但是为什么你会几乎感觉不到延迟呢?因为数据时散列到几十个,几百个硬盘上,所以速度就非常快。
于是无限的可能性就打开了,单链,双链,堆,队列,二叉数,集合,。。。。。爬虫,代理等等,只有想不到,没有做不到,你需要的只是一个new关键字,各种想都不敢想的复杂的程序将会象蝗虫一样涌现了,直到AI(人工智能)产生,人类失去存在的价值为止。
最后一句是玩笑,哈哈,欢迎大家批评指教。
相关文章推荐
- 用tensorflow 创建一个基于策略网络的Agent来解决CartPole问题
- 一个图文混排问题的解决过程
- 同一个包下的公开类编译时找不到。问题解决
- 微信公众号平台网页授权接口中获取到的授权code传递给(即一个微信公众号网页授权给)任何其他多个回调域名下的url,解决了只能设置一个网页授权回调域名的问题,解决了redirect_uri参数错误的问
- Java学习笔记--解决一个类实现多个接口的问题
- 初学Flex,在使用Webservice时遇到Xml数据绑定的一个问题,试了N个方案,均没解决。
- 解决THINKCMF后台文章的相册图集只能上传一个图片的问题
- 意外地解决了一个WPF布局问题
- 使用Spark SQL的临时表解决一个小问题
- 一个Web报表项目的性能分析和优化实践(二):MySQL数据库连接不够用(TooManyConnections)问题的一次分析和解决案例
- 关于winsock中异步通信的一个怪问题的解决。
- 解决一个maven在eclipse中M2_HOME不能调整的问题
- miniGUI1.6 IP控件自定义 续篇,解决了只能保存一个IP地址的问题
- 解决XML节点删除后会留下一个空节点的问题
- 解决查询重复数据问题的一个特列
- 终于解决了一个困扰我许久的问题:通过window.showModalDialog打开的页面,Form提交,标题丢失
- 一段对话,解决一个Exchange问题
- 解决一个maven在eclipse中M2_HOME不能调整的问题
- 【U3D日记-2016年9月2日】设计模式解决工作问题的一个实例
- 20 使用Wrapper来解决一个头疼问题