精·Android开发中的MVC框架.pptVIP

交流时间:* 第*页 MVC模式与Android * 第*页 MVC概述 MVC模式是软件工程中的一种软件架构，“Model-View-Controller”的缩写，中文翻译为“模型-视图-控制器”。 MVC模式将一个交互式应用程序分成3个组件 Model（模型）：业务逻辑层，包含核心功能和数据 并实现核心业务逻辑 View（视图）：表示层，向用户显示信息 Controller（控制器）：控制层，处理用户输入，并实现View层跟Model层的协同工作 * 第*页 MVC应用领域 具有灵活人-机界面的交互式应用程序 可以灵活选择不同的信息显示方式 可以灵活选择用户的输入方式 针对不同的用户角色，提供不同的用户界面 不同用户具有不同权限，操作的方式也有所不同 * 第*页 模型（Model） 业务逻辑层，封装了业务逻辑和数据 业务逻辑（软件的核心） 数据以及访问它们的函数（视图组件使用） 执行特定应用程序处理的过程（控制器代表用户调用） 模型对于用户来说是不可见的(M与V独立) 模型独立于特定输出表示或者输入方式(M与C独立) 用户只能通过控制器操作模型(C是M与V之间的桥梁) * 第*页 视图View 表示层。就是用户看到并与之交互的界面，通常实现数据的输入和输出功能。 从模型获得数据 通过状态查询函数实现 例如：定时刷新 * 第*页 视图View 向用户显示信息 不同的视图使用不同的方法呈现信息 每个视图组件都有一个更新函数，这个函数被模型变更通知激活 这个函数被激活（此时模型已经改变）后，将使得视图重新和模型一致 在初始化阶段，视图向模型登记请求变更通知（表） * 第*页 控制Controller 控制层。起到控制整个业务流程的作用，实现View层跟Model层的协同工作。 每个视图有一个相关的控制器组件(一一对应) 用户仅仅通过控制器与系统交互 * 第*页 控制Controller 控制器组件接受事件，并翻译成输入 事件如何发送到控制器由用户界面平台决定 事件被翻译成为对模型或者视图的请求 如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知 例如：用户点击按钮，按钮的事件响应函数将采取相应的措施处理用户要求 变更-传播机制 一个模型可对应多个视图 如果用户通过一个视图的控制器改变了模型中的数据，那么依赖于该数据的其他视图也应该反映出这样的变化 一旦模型的数据发生了变化，模型需要通知所有相关的视图做出相应的变化 维护数据的一致性 这样的方式可以通过观察者（Observer）设计模式完成 * 第*页 Android与MVC 这里以一个示例（RSS）为模板进行解释。 首先观察软件整个项目的结构，如左图所示。 M（Model）模型层 com.sharpandroid.domain：实体模型层，存放在程序中调用到的实体类。 com.sharpandroid.servier： 业务模型层，存放在程序中调用到的业务逻辑。 对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。 V（View）显示层 Android很好地将显示层抽离，并放入res/目录中以XML的形式体现。虽然对于控件属性修改可以通过Java代码完成，但还是推荐将控件的属性在XML中设置为佳，遇到动态修改的内容再采用硬编码的方式。这样增加了程序的可读性，也有利于软件后期的维护。 main.xml、shownews.xml：布局文件。 strings.xml：存放常量。 drawable：存放使用的图片文件。 C（Controller）控制层 Control是Acticity的天职，你只要告诉Acticity做什么，而至于怎么做，那是模型层的事。 这句话也就暗含了不要在Acitivity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。 如果不用MVC会怎样？ （1）这样做带来最明显的缺点就是过分的耦合。试想一下，在设计初期，没有遵循MVC进行严格的分层，而在开发中，当需要对一个方法或者一个布局进行更改时，由于层与层之间的过分耦合，那么你将面对的是“牵一发而动全身”的修改过程。如果基于MVC设计应用，我们只要修改相应层，就达到了我们的目的。 如果不用MVC会怎样？ （2）难以分工。在不使用MVC情况下，程序员要为如何设计UI用户界面头疼不已，浪费大量的精力，而不能将重点放在核心代码的编写上，降低开发效率。如果遵循MVC，就可以将视图层交给美工处理，程序员可以更好地去关心核心代码的编写，不用再被繁琐的布局所困扰。 如果不用MVC会