关注WebWork（一）
2005-10-21 23:57 FantasySoft 阅读(2495) 评论(11) 编辑 收藏 举报
大约一年前，我为一个小型项目选择框架的时候，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吧！
时光飞逝，一年过去了，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吧！
