在我已经确定在Client端完全遵守Web 标准之后，要为我的Server端考虑一下前途了。面对那么多的技术方案，谁都希望选择一个更有前途的演进方案。
在看了微软的PDC的更多视频和自己的思考以后，我做出了下面的选择。
我的选择是跳过Entity Framework 1.0，拥抱Velocity ，对Azure OS持乐观态度。
我感觉这三个东西其实反映了同一个本质性问题。
那就是哪里才是数据的家，硬盘还是内存? 原来肯定是硬盘，而现在正在有向内存迁移的趋势，而这个趋势将带来软件架构的根本性变化和相应的技术演化。
下面是一些推导过程。
首先，对程序员来说，计算机可以抽象成３大块，硬盘，内存和ＣＰＵ。这３个玩意各自有其它奇特的地方。
１，ＣＰＵ速度最快，然而容量最小，数据一进就需要赶快出来。
２，内存速度较快，容量也比较大，但是有个致命的缺点，它需要加电。
３，硬盘速度最慢，容量最大，它有一个最大的优点，断电了数据也能保存。
于是聪明的数据很快就作出了决定，硬盘才是我的家，为了更好的管理硬盘上的数据，数据库技术产生了。整个数据库技术的发展史就是围绕解决硬盘这个瓶颈而演进的。简单的说，你在写C#的代码的时候，就是在操作内存里面的数据，写SQL就是在搞定硬盘。于是聪明人就希望能够用ORM 来屏蔽掉数据库。把搞定硬盘这个脏活交给系统去完成。然而这个几乎是不可能完成的任务（注意这里说的是几乎）。为什么呢？
1, 因为数据总是要回硬盘的，无论你在内存中如何变幻，只有回到硬盘才有了语义上的意义。单个的一个日期，一个单价，甚至一个对象没有太大意义，只有放到了表结构这个语境中，数据才获得了意义。这就是commit为什么这么重要的原因。通过数据库备份技术，我们就可以保留了一堆有意义的数据。
2，从内存到硬盘的映射必然是不完全的，有缺陷的，拓扑结构不同的东西是没有办法完美映射的。学过几何的都知道，一个3厘米的线段是可以完美的投射到一个5厘米的线段，然而没有办法投射到一个方块上。
另外EF并不认为内存是数据的家， 归根到底还是映射到硬盘，只是演化的一个分支。我选择跳开这一版，反正现在还没有投入很多。 提醒一点， 如果是企业系统， 比如一个ERP, EF也是一个可行的方案， SAP的EF模型已经完美地运行了十几年了。
关于Linq to Sql, 我选择继续使用， 原因如下：
１， linq to sql本身是一个很轻型的方案
２， linq to sql 转化为 老的Ado.net 也很容易。
３， 我是主要投资到数据库的（就是大量存储过程），所以对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（人工智能）产生，人类失去存在的价值为止。
最后一句是玩笑，哈哈，欢迎大家批评指教。