MVC for Android

在Android开发中，比较流行的开发框架模式采用的是MVC框架模式，采用MVC模式的好处是便于UI界面部分的显示和业务逻辑，数据处理分开。那么问题来了，在Android项目的开发中哪些代码来充当M,V,C角色呢？下面结合Android项目的具体结构对MVC for Android 做简要剖析。

M（Model）模型层

适合做一些业务逻辑处理，比如对数据库的存取操作、对网络等的数据请求操作、复杂的算法、耗时的任务等都应该在Model里面处理，当然对业务计算等操作也是必须放在该层的。

V（View）显示层

应用层中处理数据显示的部分。Android很好地将显示层抽离，并放入“res/”目录中以XML的形式体现，所以在Android中XML布局可以视为V层，显示Model层的数据结果同时接收用户输入的信息。

C（Controller）控制层

在Android中，Activity处理用户交互问题，因此可以认为Activity是控制器，Activity读取V视图层的数据，控制用户输入，并向Model模型层发送数据请求。Control是Activity的天职，你只要告诉Activity做什么，而至于怎么做，那是模型层的事。这句话也就暗含了不要在Activity中写过多逻辑代码，要通过Activity交割Model业务逻辑层处理，这样的另一个原因是Android中的Activity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被收掉。

如果不用MVC会怎样？

这样做带来最明显的缺点就是过分的耦合。试想一下，在设计初期，没有遵循MVC进行严格的分层，而在开发中，当需要对一个方法或者一个布局进行更改时，由于层与层之间的过分耦合，那么你将面对的是“牵一发而动全身”的修改过程。如果基于MVC设计应用，我们只要修改相应层，就达到了我们的目的。
难以分工。在不适用MVC情况下，程序员要为如何设计UI用户界面头疼不已，浪费大量的精力，而不能将重点放在核心代码的编写上，降低开发效率。如果遵循MVC，就可以将视图层交给美工处理，程序员可以更好地去关心核心代码的编写，不用再被繁琐的布局所困扰。
不易维护性。在不使用MVC情况下，即使能顺利将项目开发完成，但在开发过程中用户可能对某一模块不满意，需要修改或者去除，有时需要添加新的模块，这样的事情，对于处理没有使用MVC框架模式的程序，将会是多么头疼的事情。
Android系统专门提供了"res/values/"目录下的诸如strings.xml、colors.xml类型的文件，可以将我们的常量值写入XML文件中，方便调用。这样不仅节省资源，还便于对资源的管理。如果某变量需要修改，可以直接对strings.xml文件进行修改。否则，我们需要对整个应用中所有用到该变量的代码进行修改。