[前言] 写这篇Post源于我既做过.NET开发又做过J2EE开发的经历。在这样的转变过程中，我对单一平台开发所带来的思维局限性有了很多清晰却零散的想法。在看了振河兄的页面间传递变量的方法及使用范围的讨论之后，我更能体会到在不同的平台进行开发，思维方式会是如此之不同，原来那些零散的想法也随之不断在脑海中涌现，让我有了写下这篇Post的冲动。其实我一直都在宣扬一种观点：技术之间是相通的，精于触类旁通，善于联想是我们程序员应有的优势。我们在专注.NET技术的时候，不妨在工作间隙休息的时候看看.NET外面的世界。
提到.NET和J2EE，一般都会想到它们之间兵戎相见，水火不容的关系，毕竟两者都在努力地去虏获程序员的青睐，占领更多的市场份额。我无意去鼓吹.NET是如何如何之强大，J2EE是如何如何的成熟，也无意去探究NHibernate，Sprint.NET等等Project的起源，只想从一个程序员的角度去看待两者在互相竞争的过程当中到底相互借鉴了什么，同时探讨一下同时了解两个领域知识的必要性。好，让我们言归正传。
还记得2003年初，我到了DELL公司实习，所承担的工作任务就是建立一个Web Application供多个有密切联系的部门使用，以提高部门间的协作程度。在选择用什么技术来做这个Web Application的时候，我放弃了比较熟悉的ASP，进而选择了ASP.NET。正是做这个Project，我跟ASP.NET乃至.NET结下了不解之缘。当时第一次接触到ASP.NET，第一个感觉就是，它比ASP好多了，再也不用像写ASP那样在HTML嵌套着一堆堆的Scriptlet，动态内容的呈现都包含在一个个方法中，如Page.OnInit()和Page.OnLoad()等等，这些方法让我看到Client端JS方法的影子。在开发ASP.NET页面的过程中，我需要做的就是在页面中引入不同的Web Control或者是HTML Control，这些Controls与HTML标签是何等的类似，除了它有ASP的prefix和那时看起来如Magic一般的runat="server"。这样的相似性让熟悉HTML和JS的我很快掌握了ASP.NET的基本应用，而我也以极高的效率完成了公司分配给我的任务，尽管我对诸如Request、Response、Session和Application这样的对象并不是十分了解。ASP.NET所带来的进步是革命性的，难怪有朋友认为ASP.NET是.NET家族中最为成功的产品了。我当时只是拿ASP.NET来跟ASP作对比，其优越性自然显露无遗，尤其是在控件设计方面的优势。事实上直到后来进入J2EE的开发领域，我依然对ASP.NET的开发方式赞赏有加。Microsoft在技术的创新上一直秉持削弱领域开发特性的原则，让开发人员能够在不同的开发领域中都可以轻松上手，游刃有余。ASP.NET的出现带来了WebForm，而在桌面程序开发中则有WinForm，两者相通的地方随处可见，这让原有的桌面程序开发人员可以平滑的过渡到Web Application开发中来；ASP.NET对于控件在设计以及使用上的支持堪称完美，也为网页设计人员进入ASP.NET开发领域扫除了不少的障碍。反观J2EE领域，做Swing开发的人员，如果要学习Web的开发，原有的知识几乎无用武之地了。在这个人气就是财富的年代，在一定层面上求同存异，让开发人员能够一通百通，无疑是一个十分明智的做法。J2EE领域也开始意识到了这一点，将Swing概念应用到Web开发的Wicket Framwork的发布着实是一个极大的进步啊。J2EE在降低Web开发的难度，吸引入门级开发人员方面需要向.NET好好请教一番了。
好，个人经历接着说。2003年底，我进入了一家软件公司从事J2EE的开发工作。当时公司技术部门负责人在面试我的时候提到了我缺乏J2EE的开发经验的问题，我信心满满的告诉他，我做过.NET的项目，而.NET和J2EE都是专注在企业级应用上的，因此肯定会很快上手，不会有什么问题。然而后来的工作证明了平台之间的差异性是很大的，从.NET过渡到J2EE并不是一件轻松的事情。没有了熟悉的Web Control，取而代之的是简陋的Tag Library；没有了简单易用的Event-Driven的方法，呈现眼前的是doGet、doPost、doHead和service这样看似丑陋的面孔。蜕变的过程是痛苦的，但是蜕变带来了进化。开发方式的改变让我可以从一个更加深入的层面去看待Web开发，而我开始重新认识Web Application。Web开发的复杂性在很大程度上源于Http是一个无状态的连接协议，Web Server不管你是Michael，还是Jordon，只要你在浏览器上使用了相同的URL，就会得到相同的资源。在这里，你必须清楚URL到底是什么的缩写。也许你会站出来反驳我刚才所说的结论，但是这种情况在只有静态HTML网页的年代是绝对正确的。随着时代的发展，资源已经不再局限于静态的HTML网页，随之出现了所谓的动态网页。这里的动态不是指充满Flash动画的网页，而是指网页的内容会根据不同的Request而发生变化。虽然Web的内容开始个性化了，但是仍然没有脱离Client发送Request，Server返回Response这样的模式。由于Http是一个无状态的连接协议，为了能够识别用户访问同一资源的状态，在J2EE的世界里，我们就得从Request、Response和Session这样的对象入手，控制这些对象的Life Cycle。因此，我们哪怕要进行最为简单的Web应用程序，都必须对Request、Response和Session这样的对象有充分的了解。关注这些基本的对象，让我们对于应用程序的Flow有更为准确的把握，能够更好地进行模块地划分，便于开发人员进行协作。然而在.NET的世界里，对Request和Session这样的对象关注远不如对Page的关注，从振河兄的Post就可见一斑了。ASP.NET开发降低了开发难度，却在一定程度上阻碍了开发人员对Web Application的整体把握，正如春鱼兄的Feedback中提到的，过分纠缠页面之间关系，“不利于系统整体架构的良好设计”。J2EE的应用程序可以让程序员在Web Application的整体架构上有一个很好的体现，.NET还是得好好努力啊！建议.NET的程序员能够尝试着利用J2EE的技术来开发一个简单的Web Application，我相信这样的一个过程会让你对Web开发有进一步的认识。
进入了J2EE的领域，除了开发方式变了，buzz words也跟着改变了。两个使用频率极高的词汇充斥着每天的工作，一个是MVC，另一个则是Framework。我感慨于Pattern在J2EE中使用的广泛性，感慨于应用实现了MVC模式的Framework竟然可以让庞大的团队协同开发一个Project。那时的我开始相信Pattern的广泛应用给软件开发带来的变化是巨大而深远的，也开始阅读《Core J2EE Patterns》并从中获益。而在.NET的世界里，对Pattern的重视则远不如J2EE，尽管这样的情况在改变。说到了MVC，不得不对这样一个份量很重的词汇做些陈述了。JSP的发展经历了两个阶段：JSP Model1和JSP Model2。在Model1中是JSP和JavaBean的结合，在一定程度上实现了MVC，但是Model与Control之间的耦合仍然普遍存在；而Model2则真正实现了MVC：JSP作为Presentation层，负责数据的显示；Servlet充当着一个Request Dispatcher的角色，将Request分发至不同的处理Business的模块中，它就是一个指挥官，扛着Controller这面大旗；而VO则是一个数据的载体，是MVC三角中的Model。MVC的概念是进入J2EE开发领域必备的，从你做第一个简单的应用程序开始，从你看第一篇关于J2EE开发的文章开始，而丰富的开源MVC Framework也成为了我们学习MVC Pattern的良好教材。对J2EE有了初步的认识之后，就可以选择一些优秀的MVC Framework来研究了，例如WebWork和Spring。这对于学习系统整体架构设计方面是大有裨益的。
也许物极必反真的是一条不变的真理，J2EE领域中对于开发Framework的追求可谓之疯狂，大家朝这里看：Wicket - Introduction。你会发现可以用来开发Web Application的Framework竟然达到了55个，并且还在日益增加。事实上J2EE开发的软肋不在于Control这个层面，而是在View。许多天才的精力都耗在重复制造轮子上，却没有想办法去完善一个或者多个Framework，这不得不让人感到痛心啊！在这一点，J2EE是不是得向.NET好好学习一下呢？在.NET的世界里，最受关注的应该是控件的开发了，一个设计良好，功能强大的控件对于提高开发效率无疑是极好的助推器。很多.NET的开发人员都将精力花在设计控件上，.NET就像一个聚宝盆一样，不断汇聚开发人员智慧结晶。在J2EE的世界里，为了减少这种资源浪费的情况，Wicket Framework的出现了。它强调组件设计和组件重用，让开发人员集中精力于组件的开发，从而增强Framework的功能已经易用性。但愿，Wicket Framework能够为J2EE世界带来少许的改变吧！
说着说着，真的有点野马脱缰的感觉了。不知道说了半天，大家是否明白我真正的用意呢？ 在这个技术如此Open的年代，.NET的程序员应该去了解J2EE，反之亦然。我想，相互学习，共同进步这句再普通不过的话可以概括这罗罗嗦嗦的数千字吧。
