这个星期的事情太多，现在终于有时间坐下来理一下。
在几个星期之前，我负责设计开发的那个系统开始测试，公司专门派一个人负责录入测试数据。由于这个系统太大，数据涉及全国几乎所有的区县，所以光靠一个人来录入数据是不可能的。所以，在他录入了3天之后，我决定专门写几个存储过程，来复制数据。一天下来，把全国几乎所有的县的数据都录上了。但是当我再运行系统的时候，发现系统运行的速度奇慢无比，完全无法让人接受。我不知道这个对我来说是祸还是福，但至少这个实事给了我从新思考这个系统结构的机会！我一直都想让自己具备系统分析师的能力，也在不断地学习，这件事也让我看到自己离系统分析师这个角色还有一段距离。
相关阅读
----坐在框架上的程序员
这个系统从用户的需求角度由县级客户端、市级客户端、省级客户端和部级客户端构成；从系统数据处理的角度由客户端、应用服务器和数据库服务器构成。就数据处理流程，我设计了一个构架，这个构架将数据表示、数据转换、数据网络传输、数据存储有机的结合起来，它基于.Net，在这个构架设计实施完成之后，整个系统开发的速度变得很快，基本上能够消化掉用户需求的调整，可以说是一路凯歌。但是当整个系统面对大数据的处理时，问题出来了。这个问题如果不能够很好解决，那么这个构架就得作废。
为了将数据传输到应用服务器上处理，必然会出现一大块数据在网络上传输的情况。在网络带宽有限制的地方，分布式的处理方案显然会受到影响。我了解决数据压缩问题，我在网上找到了两个解决方案。一个是在Msdn library上找到的GZipStream，一个是开源的GZip。
GZipStream提供流压缩处理，但是它是包含在.Net 2.0框架中的，要使用2.0框架，必须使用VC++2005版本，而我现在使用的是VC++2003。而开源的Gzip是用标准的C++写的。两个方案相比之下，我当然选择了前者，毕竟都是在.Net框架上。
于是我立即到微软的网站上下载了一个VC++2005的试用版，但是当我把现在的VC++2003写的项目升级到VC++2005后，我被眼前的情况惊呆了。整个项目编译不能通过，编译时报错20多处。我立即查阅了一下2.0的SDK，发现VC++2005又增加了不少的keywords。当时我的第一感觉就是恶心！
的确，我们现在有很多功能都在依赖于框架。为了使用2.0框架中的GZipStream，我不得不接受VC++2005的新元素。但是直到现在我都还在怀疑，VC++2005现在还是C++。从VC++2003中的__gc new到VC++2005中的gcnew，我们不难看出，微软在改造C++，使之更加适应托管环境下的开发，托管环境让一头在大草原上奔驰的野马变得象一头圈养的家马。
当然这些都是我的个人拙见，毕竟我和微软的工程师相比，还差很远的距离，他们所想的岂是我能所料的。事物都在发展，我现在突然想起了网络，网络上的数据传输不就是一个socket就可以搞定吗，但是现在不是涌现出了一大堆东西吗？
其实这个道理我也董，越简单的东西越容易传播，而让一件东西越简单，这背下的功夫就越难，我想微软的工程师为了VC++2005的诞生也是煞费苦心了。从大心底，我很佩服他们，我也很尊敬他们。
但是，他们托管环境也把我们给管起来了，他们设计出来的，优秀的托管环境管住的不仅仅是内存资源，还有一个一个活生生的程序员，他们的推出的一个一个优秀的构架变成了我们的一个一个的监狱（而且还是非常坚实的监狱）。特别是当前，面向服务器的设计构架，一旦成熟，我们就成了给微软(或者是其它开发商)搞二次开发的了。
上次我在我的blog中提到了开源，在这里我也想到了开源，它是一片与这里完全不同的天空。如果我们把我们在构架上开发的情形比作我们居住的水泥城市，那么开源则是大自然中的原始森林，在那里我们可以自由的呼吸，无拘无束。但是当我想离开现在居住水泥城市去那片开源的天空时，我又开始犹豫，甚至开始畏惧了。
是的，我们可以在那里获得自由，但是那里不方便，甚至很危险，很多东西都要自己去考虑，一不小心可能就会丧命的。那个地方现在可以是我寻求刺激的地方，但是还不能成为生活的地方。但是追求自由的心是不能阻止的，我还要继续经受考验！
作者:火狐设计
