微软==厨师???

    声明: 本文是本人在“头脑发热”下的产场，纯属个人观点，因些有些比喻和语气偏激再所难免，如果认为这
是一篇垃圾，那我只能对给您的思想所带来的“精神污染”和侵害深表报歉了:)
   
     这些年一直在Windows平台上做开发，坐在Microsoft这只船上，总体上感觉是自己越来越懒了，什么都
想去用现成的，如果有什么问题，基本上都会去MSDN，BAIDU或 GOOGLE上SEARCH一把，看有没有很合口味的，
如果没有自己才真正动手写些东西。

     微软在给我们提供各种开发工具和不断更新并日益强大的.net平台的同时，也让自己变成了一个瘾君子，除
了C# 和.NET框架之外，已无兴趣和耐性再去过多涉略其它领域的技术了。遥想当年学习ACE的兴趣和看JAVA编
程思想的兴奋，现在只想感叹.net这边新东东层出不穷，而再去研究和学习JAVA开源框架的时间已所剩无已。而
更让我强烈感受到的就是微软已变得越来越像是个厨子，特别是一个善于做自助餐的厨子。而我以前还喜欢亲自下
厨（写一些核心类和方法）的“瘾”已越来越少，剩下的就只是想吃现成东西的欲望了。

     而微软在一次次不断包办我们手头工作和提升开发速度的同时，他自身似乎也在不断调整他所专长的做菜风
味。还记得当前java 1.1里的匿名类吧，.net2中也推出了个匿名方法，当时我就觉得不对劲，为什么会这样，
因为与其学习对手为何不将其做菜的窍门也学过来，果然在3.5框架时也有了匿名类，虽然主要是强类型，并且还
和LINQ关系暧昧。

     而IL语言上老微更是将学会的东西发扬光大,.Net是吸取了Java的长处, 拓宽了中间语言的使用范围, 也
就是.Net的语言互操作性，不管你是用VB.Net，C#，还是J#，Managed C++，最终你编译得到的，都会是IL。
而区别是当编译为中间语言之后，Java用JVM来解析(Jdk1.5之后也采用了 JIT)，而.Net则使用JIT编译器编
译。而好处是运行效率几乎和内部机器代码。从这一点来看微软是一个不断学习的公司，它不仅从对手，也从开源
社区学了不少做菜本领。

     IOC这个东西前些年在JAVA社区炒得沸沸扬扬，而.NET这边那两年却是好像充耳不闻一样，而machine.
config和web.config现在回过头来看却颇有点像是IOC的另类实现。只不过实现得难看罢了，但谁又敢断定微
软将来不会对这种机制进行扩展和提升，使其成为依赖注入，控制反转的“温床”。

     AOP 这个“垂直90度的面向对象开发方法” , 我在园子里曾经几次看到过使用ContextBoundObject方式
实现所谓的AOP的，其实这种代码 3年前我就曾在微软的官方站点上看到过。那是一个微软技术专家（好像是意大
利人）写的。我在这里不是要去评论那篇文章，而是当初我下载运行了这个示例之后也曾兴奋了一阵子，但很快我
就越来越感觉到这个东西做为正餐前的小甜点还行，但与aspect#这样的AOP大餐来比，只能是自己亲手下厨玩玩
而已的小菜了。不管说它代码侵入范围过大也好，还是占用继承位置（它要继承ContextObject）或无法截获
static 函数也罢，最终也只是某年某月某一天的厨房秩事而已。

     而如今PIAB（Policy Injection Application Block）已内置在了Enterprise Library中，它包括Valida--
tionHandler、Logging Handler、Exception Handling Handler、Caching Handler等处理器。这
些Handler事实上对应的就是权限认证、日志、异常处理、缓存，而它们都是AOP技术所关注的地方。虽然这只是
一个开始，但我已明显感受到了这个大厨做菜的风格。那就是AOP这种技术从一开始进入到开发领域, 到有了开源
项目实现甚至还取得了一些成功之后，这位大厨嗅到了“成功”的味道，也开始钻研并制做这一道菜了，尽管AOP方
法本身还有一些问题（如测试困难等）。但我相信只要微软开始做了，那么所有问题最后都只会变成时间问题。而
微软的聪明之处就在于让别人甚至对手去制造商机和开拓市场，而真正要抢占市场时，他掏出菜刀的速度绝不比对
手慢（有点像古惑仔）。

     回过头来再说 MVC，前一阵子园子里已炒了一阵子。说真的，刚听到这个消息时，我也有点惊讶。但回过头
来一想就明白了。必定做为.net旗下最“根红苗正”的开源框架， Castle 一问世就吸引着全世界的开发者，特别
是.net阵营开发者的目光。而Castle框架本身所注重的ComponentModel模式，也是微软所推崇的。我两年多
前刚看到Castle代码时就在想：如果微软的工程师看到这个框架相信他们也会“眼热”的。而到今天微软才参考这
个框架，我这里想用郭德纲在《西征记》中的一句话来形容了：“你咋才来吔，干刷去了你?”(河南话)。必定MOR
已推出很长时间了，而微软如今才有所表示。而又一转念“如果那么多人都在关注Castle的话，微软没有理由不
有所察觉呀, 除非他又瞎又聋:)。也许正是基Castle表现的太耀眼了（里面的亮点多得就像古代皇后头上的凤冠）
。而微软又可能认为时间未到还是因为别的什么原因，导致迟迟看不到动静。

    而现在好了，微软开始为全世界开发者烧制自助大餐了，而大家要做的就是根据自身特长，公司情况以及客户
情况来制订一套用餐计划。表面上一切很好，但对于已习惯了控件开发模式的朋友来说就没那么美妙了。而这又是
必要的，因为它会解决以往“众口味难调”的问题，所以从长远角度看，只能赶紧学会做“选择题”了。并且我想以
后这个厨子做的自助餐（提供的选项）只会越来越多，花样翻新的可能性也会越来越大。所以大家要有一副好肠胃，
避免消化不良:)

     下面再说说我对 .net2框架的看法，这个框架本身这些年给我感觉它越来越像是一个过渡性的产品，里面所
说的泛型也好，匿名方法，迭代器也罢。这些东西如今都成了wcf,wpf,wf, ajax等这些大菜的“技术佐料”了。
从这一点看.net2 倒很像是正餐前的小点心，是让大家热身和准备吃.net3以及将来要发布的.net n.0 那一系
列大餐的“助消化药片”。

     这位大厨不仅从对手和社区学习，我感觉他更拿手的是在自己身长找到优势和特长，并将其发扬光大。
     webpart这个东西早在sharepoint里就有了,在.net2.0里内置到了框架中，而工作流这个微软的强势技术
(本人认为它不是产品而是技术)也是从sharepoint中嫁接过来放到.net3.5中的，微软一次次的在 .net中放入
以前成功技术和开发经验的同时，也让已熟悉这些领域的开发者平滑地在其它技术开发平台上游走。

     “群英会萃”倒底是不是“萝卜开会”呢，在WCF这里肯定不是，因为WCF就是这样一道“群英会萃”。WCF统一了
分布式技术的写法，管它什么webservice,remotion,msmq，Enterprise Service呀，通通一勺烩，驻留组
件服务，声明性操作，多通信信道（http,tcp,ipc），安全体系结构，可扩展性，根本不用改写已有分布解决方
案。这道菜的“风味”还可以继续做下去，但有上面几个就够让人流口水的。

     而如今的linq更是在对ORM已有的体系结构产生巨大冲击, 大家可以看看这篇文章是怎么说的:)
     http://msdn2.microsoft.com/zh-cn/library/aa730866(vs.80).aspx#EIAA

     InfoPath，OneNet这样的产品在微软旗下多如牛毛，而下面的这个链接就是超哥（开心就好）所做的一个简
介(http://blog.joycode.com/joy/archive/2004/04/28/20392.aspx),而这些产品的目标就是将你们
公司的前台MM或那些菜鸟也变成“开发者”，从这一点看，微软做的菜太周到了，周到的程度已让人感到了“毛骨悚然”。
在大学时老师就说，软件开发从业者就是自已的“掘墓人”，而从现阶段看，我们挖坟的速度已然让厨师超过了:(
   

     这位大厨除了是优秀厨师之外，他还爱好体育运动。为什么这么说呢？因为我在teched2007中的一次课程上
听一个演讲嘉宾说微软是一位“长跑冠军”。尽管他语一出，旁边的讲师就马上修正了这个“语病”。但做过产品开发
的朋友都会知道这意味着什么, 因为产品开发（研发）从来不是像做项目一样，如果将做项目看成是“百米冲刺”的
话，那做产品就是在参加“马拉松”了，甚至有可能连终点都没有, 所以对于小公司而言，做产品就像是钻一个“无
底洞”。而与长跑冠军做对手的下场, 相信大家都会知道了。  

     好了，就写这些吧，必定我只是一位普通得不能再普通的软件从业人员，在国内 38%的技术从业人员都要靠
微软技术养活（CSDN统计）的这个从业大军中，我太无足轻重了。

     最后要声明的是，为什么要将微软比喻成厨师，原因很简单，因为本人就好吃，同时也很“懒做”，并且已
变得越来越懒。有现成的东西，除非它不对味，否则决不亲自下厨:)