mvc框架.docVIP

Administrator 09:45:59 (多人发送) 目前常用的MVC框架，除了Struts 2的两个前身外，还有一些非常流行的MVC框架，这些框架都提供了较好的层次分隔能力。在实现良好的MVC 分隔的基础上，还提供一些辅助类库，帮助应用的开发。 目前常用的MVC框架还有如下一些。 1．JSF 准确地说，JSF是一个标准，而不是一个产品。目前，JSF已经有两个实现产品可供选择，包含Sun的参考实现和Apache的MyFaces。大部分的时候，我们所说的JSF都是指Sun的参考实现。目前，JSF是作为JEE 5.0的一个组成部分，与JEE 5.0一起发布。 JSF的行为方法在POJO中实现，JSF的Managed Bean无需继承任何特别的类。因此，无需在表单和模型对象之间实现多余的控制器层。JSF中没有控制器对象，控制器行为通过模型对象实现。 当然，JSF也允许生成独立的控制器对象。在Struts 1中，Form Bean包含数据，Action Bean包含业务逻辑，二者无法融合在一起。在JSF中，既可以将二者分开，也可以合并在一个对象中，提供更多灵活的选择。 JSF的事件框架可以细化到表单中每个字段。JSF依然是基于JSP/Servlet的，仍然是JSP/Servlet架构，因而学习曲线相对简单。在实际使用过程中，JSF也会存在一些不足： — 作为新兴的MVC框架，用户相对较少，相关资源也不是非常丰富。 — JSF并不是一个完全组件化的框架，它依然是基于JSP/Servlet架构的。 — JSF的成熟度还有待进一步提高。 2．Tapestry Tapestry并不是一种单纯的MVC框架，它更像MVC框架和模板技术的结合，它不仅包含了前端的MVC框架，还包含了一种视图层的模板技术，使用Tapestry完全可以与Servlet/JSP API分离，是一种非常优秀的设计。 通过使用Tapestry，开发者完全不需要使用JSP技术，用户只需要使用Tapestry提供的模板技术即可，Tapestry实现了视图逻辑和业务逻辑的彻底分离。 Tapestry使用组件库替代了标签库，没有标签库概念，从而避免了标签库和组件结合的问题。Tapsetry是完全组件化的框架。Tapestr只有组件或页面两个概念，因此，链接跳转目标要么是组件，要么是页面，没有多余的path概念。组件名，也就是对象名称，组件名称和path名称合二为一。 Tapestry具有很高的代码复用性，在Tapestry中，任何对象都可看作可复用的组件。JSP开发者是真正面向对象，而不是URL解析。对于对页面要求灵活度相当高的系统，Tapestry是第一选择。精确地错误报告，可以将错误定位到源程序中的行，取代了JSP中那种编译后的提示。 因此，笔者一直对Tapestry情有独钟：如果技术允许，使用Tapestry会带给整个应用更加优雅的架构，更好的开发效率。 但是，在实际开发过程中，采用Tapestry也面临着一些问题必须考虑： — Tapestry的学习曲线相对陡峭，国内开发群体不是非常活跃，文档不是十分丰富。官方的文档太过学院派，缺乏实际的示例程序。 — Tapestry的组件逻辑比较复杂，再加上OGNL表达式和属性指定机制，因而难以添加注释。 3．Spring MVC Spring提供了一个细致完整的MVC框架。该框架为模型、视图、控制器之间提供了一个非常清晰的划分，各部分耦合极低。Spring的MVC是非常灵活的，它完全基于接口编程，真正实现了视图无关。视图不再强制要求使用JSP，可以使用Velocity、XSLT或其他视图技术。甚至可以使用自定义的视图机制——只需要简单地实现View接口，并且把对应视图技术集成进来。Spring的Controllers由IoC容器管理。因此，单元测试更加方便。 Spring MVC框架以DispatcherServlet为核心控制器，该控制器负责拦截用户的所有请求，将请求分发到对应的业务控制器。 Spring MVC还包括处理器映射、视图解析、信息国际化、主题解析、文件上传等。所有控制器都必须实现Controller接口，该接口仅定义ModelAndView handleRequest（request，response）方法。通过实现该接口来实现用户的业务逻辑控制器。 Spring MVC框架有一个极好的优势，就是它的视图解析策略：它的控制器返回一个ModelAndView对象，该对象包含视图名字和Model，Model提供了Bean的名字及其对象的对应关系。视图名解析的配置非常灵活，抽象的Model完全独立于表现层技术，不会与任何表现层耦合：JSP、Velocity或者其他的技术——都可以和Spring整合。 但相对于