学习android开发MVC的内容

　　学习Android开发的过程中，需要学习了解MVC。那么MVC是Model View Controller的缩写，是模型(model)-视图(view)-控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

　　写道

　　在Android应用程序中，我们不能够非常清楚地区分androidMVC结构中的视图部分和控制器部分。Android框架期望开发者们将Activity基础类作为UI处理，这也就意味着一个Activity需要负责视图与控制器两个部分的任务。

　　利用观察者模式将Model进行绑定处理。

　　Android近期学习总结——开发笔记 写道

　　Android采用了典型的MVC结构。其表现如下：

　　View既可以通过xml(layout目录下)生成，也可以通过硬编码的方式直接通过代码生成。对于xml中的View资源，可以在代码中通过getViewById()的方法获得。

　　Model既可以通过xml(values目录下)生成，也可以硬编码的方式直接在代码中指定。View和Model通过Adapter来进行连接。典型的Adapter包括ArrayAdapter(可以Sort()操作)、CusorAdapter(从Cusor中查询到数据源),ListAdapter、SimpleAdapter(最常用)、SpinnerAdapter(它是一个接口，设置Spinner应用SimpleAdapter的setDropDownResource方法)。

　　谈对android开发的认识写道

　　Android应用开发一般来说由四大块构成 activity, intent, provider, broadcastreciver.

　　从这种结构上来看，android系统是提供了从显示层到数据层到消息机制的一整套的应用开发方案，而且是一种比较先进的解决方案。

　　从写android代码的过程中，android项目整体是一种典型的MVC结构，非常类似于主要用于Web开发的J2EE架构。

　　xml布局文件是view相当于JSP页面; activity和intent起到了controller的作用; provider对数据层做了良好的封装，而且provider把数据管理的范畴从数据库泛化到了数据的概念，不光管理数据记录，只要是数据文件(图片、视频、声音文件、所有其他的一切的file)都纳入管理，且提供了数据共享的机制，这是比较出彩的地方; broadcastreceiver提供了一种良好的消息机制，使得一个应用不再是一个信息孤岛，而是和其他的应用、服务等构成了信息网络，从而极大的丰富了应用的开发空间，给了应用开发者极大的想象创造的可能。

　　在看了上述讨论后，我受益匪浅。按照以前开发RoR的经验，总觉得如果仅仅将xml布局看作View层未免太单薄，而且负责渲染与事件绑定的工作也全部落到了Activity的头上，这看上去不太合理。不过另一方面说，这看上去不合理的原因是自己见识的太少以及教条主义的影响。

　　那么究竟该如何划分这几层结构呢?我觉得可以换个思路出发，我们究竟该如何合理地组织一个Android应用程序呢?我们不必教条地、具有成见地将原先系统划分结构带入到这样一个新的框架结构中，而是需要在这个特定结构中发挥其框架的效果：

　　xml布局负责将界面布局做好，并且尽量做到合理分割与减少层次

　　Activity做好控件事件绑定与业务流程控制

　　Intent做好Activity间的session传递管理

　　自己创建Model(可以通过Observer模式进行绑定处理、并且包装好各种provider)将处理数据的工作做好。不建议简单地将各个数据字段散乱地存放在Activity周围，而是借助数据Bean的思路存放在Model下面，这样在Model数据项变得庞大后难于管理与重构，而且这多为非面对对象的设计方案。

　　Adapter是数据与呈现的粘合剂

　　以上是个人在做了个Android的一个小应用后的反思与看法，整体上层次是非常低的。在这次开发中，我看到了自己在做客户端软件方面的一些问题，先分享与大家，希望能够共勉：

　　上手新框架时，成见较多，借助以前的思路机械搭建应用。这样没有合理发挥Android框架的优势，做了很多无用功。

　　整个知识网络的整合上面有欠缺，在做RoR时能够良好地利用Bean做数据传递与统一化工作。而在客户端程序时，将数据字段散乱的放在了Activity中。产生这个问题一方面来源于自己的懒惰，因为刚刚开始处理时字段就一个，所以就直接放上去了;到后来数据项激增，但是思路却没有变化。

　　Observer模式是个不错的方案，在应用开发中却没有应用。我觉得这也是在做RoR时的一些问题，和ASP.net不同(事件驱动，容易考虑到观察者模式)，RoR多为URL传递后行为触发，各种行为被自然放在了control中。而在Android应用中，错误地将Activity简单地当作了Control，将业务控制逻辑放在了里面最后忘却了观察者模式。

　　测试->开发->重构，的模式可以进一步上升一个层次，对整个流程再重构，这样不至于陷入思维陷阱。

　　Android之MVC模式

　　MVC (Model-View-Controller)：M是指逻辑模型，V是指视图模型，C则是控制器。一个逻辑模型可以对于多种视图模型，比如一批统计数据你可以分别用柱状图、饼图来表示。一种视图模型也可以对于多种逻辑模型。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式，而C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新，这与《设计模式》中的观察者模式是完全一样。

　　MVC好处：从用户的角度出发，用户可以根据自己的需求，选择自己合适的浏览数据的方式。比如说，对于一篇在线文档，用户可以选择以HTML网页的方式阅读，也可以选择以pdf的方式阅读。从开发者的角度，MVC把应用程序的逻辑层与界面是完全分开的，最大的好处是：界面设计人员可以直接参与到界面开发，程序员就可以把精力放在逻辑层上。而不是像以前那样，设计人员把所有的材料交给开发人员，由开发人员来实现界面。在Eclipes工具中开发Android采用了更加简单的方法，设计人员在DroidDraw中设计界面，以XML方式保存，在Eclipes中直接打开就可以看到设计人员设计的界面。

　　Android中界面部分也采用了当前比较流行的MVC框架，在Android中：

　　1) 视图层(View)：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入。当然，如何你对Android了解的比较的多了话，就一定可以想到在Android中也可以使用javaScript+HTML等的方式作为View层，当然这里需要进行Java和Javascript之间的通信，幸运的是，Android提供了它们之间非常方便的通信实现。

　　2) 控制层(Controller)：Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

　　3) 模型层(Model)：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。

　　在Android SDK中的数据绑定，也都是采用了与MVC框架类似的方法来显示数据。在控制层上将数据按照视图模型的要求(也就是Android SDK中的Adapter)封装就可以直接在视图模型上显示了，从而实现了数据绑定。比如显示Cursor中所有数据的ListActivity，其视图层就是一个ListView，将数据封装为ListAdapter，并传递给ListView，数据就在ListView中现实。

　　Android鼓励弱耦合和组件的重用，在Android中MVC的具体体现如下：

　　1) 视图层(View)：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入，当然，如何你对Android了解的比较的多了话，就一定可以想到在Android中也可以使用JavaScript+HTML等的方式作为View层，当然这里需要进行Java和JavaScript之间的通信，幸运的是，Android提供了它们之间非常方便的通信实现。

　　2) 控制层(Controller)：Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

　　3) 模型层(Model)：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。

       总结上文，主要学习了MVC的基本内容，其MVC 中M是指逻辑模型，V是指视图模型，C则是控制器，在MVC框架中介绍了视图层(View)、控制层(Controller)和模型层(Model)等等相关知识。