web开发框架比较课件.ppt

其它关注点：page driven 所谓driven，就是在开发应用时，以页面为主导，程序为辅助。这种模式可以比较快和直观地开发应用。 Spring和webwork都不支持这种模式。Spring2.0虽然增加了CoC的功能（Convention over Configuration），但为了实现它仍然需要相当多的配置。 Tapestry可以做到driven。在tapestry中，只要创建一个普通的html页面，就可以显示出来——即使page的程序还没写。 其它关注点：侵入性 所谓侵入性，就是指应用的代码依赖多少框架的代码。最理想的情况，是没有依赖，但这个很难做到。比较好的情况是只依赖一些特定的接口，而这些接口越简单越好，同时接口本身和框架之间也是松散耦合。 这一点Spring做得比较好： 首先，Spring MVC的核心Controller接口非常简单，只有一个方法。 其次，Controller接口和Spring MVC之间的耦合只是通过一个HandlerAdapter完成的，除此之外没有任何关联。 Tapestry的侵入性最大，但是据说其后续版本将改良这一点，引入POJO编程。 Webwork的侵入性也比较小，Action接口并不复杂。但Action接口是webwork的核心类，和webwork耦合很紧，所以其侵入性比Spring略大一些。 较低的侵入性意味着较好的扩展性、较易于测试、较好的系统结构。 过度追求低侵入性，也是有问题的。因为基于接口的编程可以利用编译器的检查，而假设侵入性为零，那意味着连接口也不能用了，这样就只好通过配置或者convention来定义规则，这样不一定比使用接口要好。 其它关注点：基于request vs. 基于对象 Webwork、Spring都是基于request的Web框架。 优点：简单易用；对request和response有直接的控制。 缺点：和WEB结合太紧；难以实现页面/组件之间的关联、重用等高级功能。 Tapestry是基于Object的Web框架。 优点：易于实现页面/组件的重用；可创建出非常复杂的可重用组件：DatePicker、Tree等，也可非常方便地实现JavaScript组件；书写页面显得很结构化。 缺点：对request和response没有直接的控制，以至于做一些简单的HTTP操作也显得很麻烦，例如：重定向；页面过于结构化，导致一些页面显得很笨拙。 其它关注点：Service model vs. Bean model Service model，就是像Tapestry所基于的Hivemind的模式。 Bean model，就是像Webwork所基于的xwork，以及Spring的模式。 Bean model可以看作是简化的Service model，但service model包含更多的内容： Service model最重要的一点是：Service的提供者和使用者，两者权责的分离。 另一个重要点是：Service包含一个service的定义，而bean只是一堆相对无意义的properties而已。 两者均支持IoC、AoP。 但Service model支持搭建更复杂的对象层次，而bean model只能在一个“平面”的层次中工作。这实际上是Spring MVC和Tapestry最本质的区别。 然而HiveMind的思路虽然绝妙，实现上却还没达到完美，以至于有的情况下会很麻烦。 我们框架的发展方向 每一个框架都有它的独特优点，也有它的不足。 作为一个希望持续发展的公司，一定要有一套完整的开发平台（包括框架、工具、开发流程等）。 我希望能够开发出一套集各家之所长，又融入我们现有优点的框架，以及相应的开发工具： Citrus （Service框架） Citrus Web （下一代的Webx框架） Citrus Studio （一组eclipse插件，方便开发） Citrus Xyz （不止是WEB应用，任何其它应用都可基于这一平台） 何谓本质？初学Web框架的人，常常会看到这个框架的配置文件是怎么写的，数量有多少，用了jsp或velocity等格式来展现内容等等，这些其实都是表象。要理解一个框架的思想，必须深入到它的内部，去了解它的实质。也许一个框架使用起来很麻烦，配置文件很多，但其实质中包含了很多好思路，值得我们学习的。所以希望这个培训能够给大家一个感觉，让大家能够去思考一个框架的本质，以便更好地发展我们自己的框架。 无论什么Web框架，无论以什么方式，最终它们都要完成上述的基本任务。 框架的本质就是扩展，对于Web框架，每创建一个页面，每定义一个action，都是对框架的一种扩展。从这个意义来讲，如何扩展，有哪些地方可被扩展，扩展的难易程度，就构成了不同框架之