Android与MVC 模式

1．M（Model）模型层

com.sharpandroid.domain：实体模型层，存放在程序中调用到的实体类。

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

2．V（View）显示层

Android很好地将显示层抽离，并放入"res/"目录中以XML的形式体现。虽然对于控件属性修改可以通过代码完成，但还是推荐将控件的属性在XML中设置为佳，遇到动态修改的内容再采用硬编码的方式。这样增加了程序的可读性，也有利于软件后期的维护。

main.xml、shownews.xml：布局文件。

strings.xml：存放常量。

drawable：存放使用的图片文件。

3．C（Control）控制层

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

试想一下，如果不用MVC模式，可能我们的代码会看起来相对简洁，而且我们一样可以完成应用，甚至将尽量多的代码都写入Activity文件，那样应用的层次会更加简洁。可是，结合MVC的设计模式思考一下，除了带来相对简洁的编程（注意，我们这里说的是相对），还会带来什么？

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

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

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

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