软件架构实践71.pptVIP

可插入的控制器 视图和控制器之间可以分离以支持一个视图与不同控制器的组合。 这种灵活性可以用来实现操作的不同模式，例如：不同的用户，或在应用中，集成新的输入/输出设备。 MVC的更进一步发展 视图 控制器 模型 视图 控制器1 模型 控制器2 控制器3 层次化视图和控制器的基础结构 一个用户的视图，可以对应一组事先构建好的控制器对象，可以考虑组合（composite）设计模式来实现这样的处理。在控制器与模型之间，则采用外观模式，提供统一的接口 MVC的更进一步发展 视图 控制器1 模型 控制器2 控制器3 视图与控制器的组合 组合模式 外观模式 MVC的更进一步发展 层次化视图和控制器的基础结构 当有多个控制器的时候，可以考虑职责链（Chain of Responsibility）设计模式来处理。 视图 控制器2.1 模型 控制器3.1 控制器4.1 控制器1 控制器2.2 控制器3.3 控制器3.2 控制器4.3 控制器4.2 …… 控制器的责任链 进一步去除系统依赖性 可以考虑建立一个视图类和控制器类的集合，希望这些类的实现是平台无关的。 可以考虑使用桥接（Bridge）模式，在这些类和基础平台软件之间建立一个隔离层。 MVC的更进一步发展 优点： 可以为一个模型在运行时，同时建立和使用多个视图。变更-传播机制可以确保所有相关的视图及时得到模型数据的变化，从而使所有关联的视图和控制器做到显示与行为同步 可插入的视图和控制器 视图与控制器的可接插性，允许更换视图和控制器对象，并且可以根据需求动态地打开或关闭，甚至在运行期间进行对象替换 模型的可移植性 因为模型是独立于视图的，所以，可以把一个模型独立地移植到新的平台上，需要做的只是在新平台上对视图和控制器进行修改 潜在的框架结构 可以基于此模式，建立应用系统的灵活框架，不仅仅只在涉及界面的设计中（MVC的进一步发展） 5、MVC的变化与评价 缺点1： 增加了系统的复杂性 有时获得的灵活性并不大，但是却增加了系统的复杂性（控制器作用并不大，但系统层次增加）。 潜在的更新因素导致系统紊乱 有时一个用户动作就导致很多更新。有些更新并不是所有的视图都关心。对动作的错误理解，导致整体信息紊乱。 视图和控制器之间的紧密联系 控制器和视图之间的联系非常紧密，妨碍了模块的独立性。 视图和控制器与模型的紧密耦合 视图和控制器直接调用模型。模型接口的改变会使得视图和控制器的代码过时。 5、MVC的变化与评价 缺点2： 视图中数据访问的低效率 数据访问依赖于模型接口。可能过多地访问不必要的数据。 增加控制器层次，降低了访问模型的效率，特别是大用户数的情况下。 移植时对视图和控制器的修改是不可避免的。 视图和控制器中的软件包含了平台相关的东西。 借用现代的用户接口工具使用MVC的困难性 现代的用户接口工具中提供了预制的控制流管理，内部事件的处理等，对MVC支持困难 5、MVC的变化与评价 Web应用面临的困难以及Web构架的解决方法 Web应用的需求 客户端使用Web浏览器 使用Web协议（HTTP协议） Web应用的好处： 与应用/平台无关的浏览器和标准的THHP协议，使得在世界的任何地方，都可以访问Web应用 Web应用的限制： 客户端方面 HTTP方面 5、MVC的实现——Struts Web应用面临的困难以及Web构架的解决方法 Web应用的限制：客户端方面 浏览器是处于Web应用程序控制之外的第三方软件 所有的浏览器都不是完全相同的，支持不同的标准子集 通过浏览器的输入有可能是不正确的，甚至是攻击 标准的Web格式语言——HTML不能完全构造出桌面应用程序所希望呈现的所有界面元素 应用程序是通过默认数据来创建HTML控件的 5、MVC的实现——Struts Web应用面临的困难以及Web构架的解决方法 Web应用的限制：HTTP方面 在默认的状态下，HTTP可以接受从网上来的任何客户的连接请求 HTTP主要是用来传送简单文本的，传送二进制数据需要使用更复杂的扩展协议 HTTP是无状态的，因此，需要特别的方法来跟踪使用Web应用程序的用户 HTTP是可信的，它期待用户端发回正确的信息 问题小结：应用的鲁棒性 5、MVC的实现——Struts Web应用面临的困难以及Web构架的解决方法 为什么基于Web的构架，可以解决上述缺点？ 5、MVC的实现——Struts 软件架构实践 SOFTWARE ARCHITECTURE IN PRACTICE 软件系统设计与体系结构 软件架构实践 第 7章 基于MVC设计模式的架构设计与实现 7.1 面向对象的MVC设计模式 7.2 基于MVC的Struts应用框架 7.3 搭建一个简单的Struts应用框架 7.4 SSH框架的技术