MVC设计模式

Android中MVC设计模式:

MVC设计模式是为了让编程工程项目层次化，使之分工明确，便于设计项目工程和后期修改维护。

M:model

实现具体的功能代码，业务逻辑。

如：
com.sharpandroid.domain：实体模型层，存放在程序中调用到的实体类。
com.sharpandroid.service：业务模型层，存放在程序中调用到的业务逻辑。

V:view

实现界面UI。

Android很好地将显示层抽离，并放入”res/”目录中以XML的形式体现。虽然对于控件属性修改可以通过代码完成，但还是推荐将控件的属性在XML中设置为佳，遇到动态修改的内容再采用硬编码的方式。这样增加了程序的可读性，也有利于软件后期的维护。
main.xml、shownews.xml：布局文件。
strings.xml：存放常量。
drawable：存放使用的图片文件。
Control是Acticity的天职，你只要告诉Acticity做什么，而至于怎么做，那是模型层的事。

C:Control

作为M和V的桥梁，使之有条理的协调工作。

Control是Acticity的天职，你只要告诉Acticity做什么，而至于怎么做，那是模型层的事。

若不使用MVC：

（1）这样做带来最明显的缺点就是过分的耦合。试想一下，在设计初期，没有遵循MVC进行严格的分层，而在开发中，当需要对一个方法或者一个布局进行更改时，由于层与层之间的过分耦合，那么你将面对的是”牵一发而动全身”的修改过程。如果基于MVC设计应用，我们只要修改相应层，就达到了我们的目的。

（2）难以分工。在不使用MVC情况下，程序员要为如何设计UI用户界面头疼不已，浪费大量的精力，而不能将重点放在核心代码的编写上，降低开发效率。如果遵循MVC，就可以将视图层交给美工处理，程序员可以更好地去关心核心代码的编写，不用再被繁琐的布局所困扰。虽然现在Android的布局并不是十分复杂，可是随着Android的发展，这必然是一个趋势。

（3）不宜维护性。在不使用MVC情况下，即使能顺利将其开发完成，但在开发过程中用户可能对某一模块不满意，需要修改或者去除，有时需要添加新的模块，这样的事情，对于处理没有使用MVC设计模式的程序，将会是多么头疼的事情。

（4）Android系统专门提供了”res/values/”目录下的诸如strings.xml、colors.xml类型的文件，可以将我们的常量值写入XML文件中，方便调用。这样不仅节省资源，还便于对资源的管理。如果某变量需要修改，可以直接对strings.xml文件进行修改。否则，我们需要对整个应用中所有用到该变量的代码进行修改。

原文地址