ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 关注WebWork(一)

关注WebWork(一)

原创 Linux操作系统 作者:hejian2002 时间:2019-07-13 17:54:06 0 删除 编辑
大约一年前,我为一个小型项目选择框架的时候,WebWork第一次进入了我的视野,它优美的设计以及强大的功能,再配以平缓的学习曲线深深打动了我。在一番比较过后,我毫不犹豫地选择了WebWork并用它顺利完成了这个项目,并且在开发过程中写了不少总结性的文章。尽管WebWork有着这样那样的优势,但是它本身仍然存在着诸多的不足,社区不够活跃,更新速度太慢,最糟糕的就是文档太少且质量参差不齐,这些因素都使得WebWork并没有如期待那样流行,而我写的文章也鲜有人浏览就是明证。去年在写完了深入探索WebWork系列最后一篇之后,我就把WebWork暂时放到了一边。
时光飞逝,一年过去了,WebWork就在我不经意间悄悄地发展,从我最初使用的2.1.2到2.1.7再到现在2.2beta,而我写的
《WebWork初体验》也悄无声息地爬上了阅读量的排行榜,扣除有关股票的那篇Post不计,这篇文章已经成为了技术方面最受关注的文章。在最近我也不时收到一些朋友给我发来的mail询问有关WebWork的问题,这也让我点受宠若惊。这个曾经让我如此心动的框架再次闯入了我的IT生活,牵动着我的心。随着WebWork2.2beta的发布,随着大家对WebWork关注程度的提高,随着《WebWork in Action》的出版,随着......我想是时候重新扬帆,为推广这个从过去到现在都让我赞叹的框架出一点点力了。而我最先想到的自然就是翻译《WebWork in Action》。
《WebWork in Action》是一本翘首企盼了很久的书,它的分量之重自然不需要多言了。我来翻译这样一本书,确实有点高攀了,但这是一本值得细细品味的书,翻译则是一个很好的驱动力,促使自己更加专注的研读每一段,每一字句。至于翻译的文字能否面世,则需要看机会了,但不管怎么样,我一定会完成这样一项工作,哪怕我的文字艰深晦涩,无人喝彩,我也会敝帚自珍,将这些译文好好收藏。呵呵~~~
好了,说了那么多废话,也该说说正题了。经过一个星期的努力,终于把该书的第一章给翻译完毕了,鉴于版权的问题,我不能把这些文字公布出来让大家扔鸡蛋,但是我仍然想说说自己在看完并译完第一章之后所得到的启发。
第一章是对WebWork的概述。在讲述WebWork的特性之前,作者花了相当的篇幅对MVC的作用以及发展做了介绍。通过这些介绍,你可以了解到MVC的产生是为了解决GUI应用程序中存在的紧耦合问题。这里的紧耦合是指域对象逻辑与显示逻辑之间的紧密耦合,为了能够将业务逻辑从显示层面的代码中剥离出来,MVC模式派上了极大的用场。然而这样一个具有历史意义的模式并不能直接应用到Web环境中,因为HTTP并不是有状态的连接协议,而Web应用程序都被抽象成了Request/Response形式。因此稍作改变的MVC才能很好地为Web应用程序所用,这变化的MVC通常有两种——Front Controller与Page Controller。对于这两个名词,很多朋友应该都不会陌生了,很多流行的J2EE框架使用的就是前者,而ASP.NET则是后者的拥趸。首先,Front Controller的出现是因为在Web环境下,View并不是一个可以独立更新的对象,而是一个由请求引发其本身render的画面,因此,在经典的MVC中Model与View直接通信的情况就不复存在了。取而代之的是Controller与View通信,而View则通过Request Dispatcher来匹配不同的Controller,由Controller更新Model,再由Controller返回一个值,根据不同的返回值render不同的View,同时Controller将需要显示的数据Push至View中。而Page Controller则经典MVC模式进化的另外一种方式。与Front Controller相比,Page Controller在结构上则要简单得多,并不存在Request Dispatcher这个部分。大家可以发现,在ASP.NET中,Browser请求的是.aspx资源,而一个.aspx则与一个Page类的派生类对应,其中可能包含了OnLoad, OnRender以及响应Control事件的自定义方法,由这些方法中的某一个来完成View的render工作,这个由Page类派生出来的子类就是Page Controller。Page Controller模式在解耦合方面不算称职,但是它的开发效率极高,在Visual Studio这类开发工具的支持下尤为突出。这两种模式各有优势,而WebWork对它们都提供了良好的支持,给开发者留下了可选择的空间。
在讲完了MVC之后,作者又对Framework和Container作了深入的阐述和比较。偶认为这一节的文字是第一章最为精彩,且最有价值的。文中引用了WebWork缔造者Rickard Oberg的妙语对框架做出解释:A framework's power comes not from what it allows, but from what it does not allow. Framework强调的是限制,其中有组织结构的限制,也有Flow的限制。这样的限制可能减少了你大展拳脚的机会,却会给你的应用程序带来清晰的脉络结构,更加重要的是可以使得一个团队进行协作开发,开发效率得到提高,软件的规模也会随之扩大。这就是框架所带来的巨大作用。与Framework相反,Container则不是专注在限制,其目的是提供一个环境来装载特定的对象,并增强这些对象的功能性,同时又不影响对象之间的独立性。Servlet Container和EJB Container,还有很hot的Inversion of Control Container都具有这样的特性。WebWork是两者的组合体,除了提供框架之外,还为开发人员提供一个Lightweight Container。在第一章剩下的篇幅里,作者还回顾了WebWork的发展史并展望了未来。嗯,未来真的很诱人。
好了,对第一章的感受就讲到这里了,但愿各位也能够随我一起关注WebWork吧!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16629/viewspace-78730/,如需转载,请注明出处,否则将追究法律责任。

上一篇: ANT的培训内容
下一篇: 关注WebWork(三)
请登录后发表评论 登录
全部评论

注册时间:2002-07-16

  • 博文量
    20
  • 访问量
    14306