在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文件进行修改。否则,我们需要对整个应用中所有用到该变量的代码进行修改。