MVC模式是软件工程中的一种软件架构，“Model-View-Controller”的缩写，中文翻译为“模型-视图-控制器”。
MVC模式将一个交互式应用程序分为3各组件：
1、Model（模型）：业务逻辑层，包含核心功能和数据并实现核心业务逻辑。
2、View（视图）：表示层，向用户显示信息。
3、Controller（控制器）：控制层，处理用户输入，并实现View层跟Model的协同工作。
MVC的应用领域：
1、具有灵活人-机界面的交互式应用程序。
a、可以灵活选择不同的信息显示方式。
b、可以灵活选择用户的输入方式。
2、针对不同的用户角色，提供不同的用户界面。
不同用户具有不同权限，操作的方式也有所不同。
Model（模型层）
※业务逻辑层，封装了业务逻辑和数据
业务逻辑（软件的核心）；
数据以及访问它们的函数（视图组件使用）；
执行特定应用程序处理的过程（控制器代表用户调用）；
※模型对于用户来说是不可见的（M与V独立）
※模型独立于特定输出表示或者输入方式（M与V独立）
※用户只能通过控制器操作模型（C是M与V之间的桥梁）
※对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在该层的，就是应用程序中二进制的数据。
View（视图层）
※表示层，就是用户可以看到并与之进行交互的界面，通常实现数据的输入和输出功能。
※从模型获取数据
通过状态查询函数实现，例如定时刷新。
※向用户显示信息
不同的视图使用不同的方法呈现信息
每个视图组件都有一个更新函数，这个函数被模型更新通知激活
这个函数被激活（此时模型已经改变）后，将使得视图重新和模型一致
在初始化阶段，视图向模型登记请求变更通知
※Android很好地将显示层抽离，并放入“res/”目录中以XML的形式体现，虽然对于控件属性修改可以通过Java代码完成，但还是推荐将控件的属性在XML中设置为佳，遇到动态修改的内容再采用硬编码的方式。这样增加了程序的可读性，也有利于软件后期的维护。
Controller（控制层）
※控制层，起到控制整个业务流程的作用，实现View层跟Model层的协同工作
※每个视图有一个相关的控制器组件（一一对应）
※用户仅仅通过控制器与系统交互
※控制器组件接收事件，并翻译成输入
事件如何发送到控制器由用户界面平台决定
事件被翻译成为对模型或者视图的请求
如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知
例如：用户点击按钮，按钮的事件响应函数将采取相应的措施处理用于要求
※Controller是Activity的天职，你只要告诉Activity做什么，而至于怎么做，那是模型层的事。这句话也就暗含了不要在Activity中写代码，要通过在Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Activity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。
变更-传播机制
※一个模型可对应对个视图
如果用户通过一个视图的控制器改变了模型中的数据，那么依赖于该数据的其他视图也应该反映出这样的变化。
一旦模型的数据发生了变化，模型需要通知所有相关的视图做出相应的变化。
※维护数据的一致性
这样的方式可以通过观察者（Observer）设计模式完成
如果不用MVC会怎样？
※这样做带来最明显的的缺点就是过分的耦合。试想一下，在设计初期，没有遵循MVC进行严格的分层，而在开发中，当需要对一个方法或者一个布局进行更改时，由于层与层之间的过分耦合，那么你将面对的是“牵一发而动全身”的修改过程。如果基于MVC设计应用，我们只要修改相应层，就达到了我们的目的。
※难以分工。在不适用MVC情况下，程序员要为如何设计UI用户界面头疼不已，浪费大量的精力，而不能将重点放在核心代码的编写上，降低开发效率。如果遵循MVC，就可以将视图层交给美工处理，程序员可以更好地去关心核心代码的编写，不再被繁琐的布局所困扰。
※维护性。在不适用MVC情况下，即使能顺利将其开发完成，但在开发过程中用户可能对某一模块不满意，需要修改或者去除，有时需要添加新的模块，这样的事情，对于处理没有使用MVC设计模式的程序，将会是多么头疼的事情。
※Android系统专门提供了“res/values/”目录下的诸如strings.xml、colors.xml、dimens.xml类型的文件，可以将我们的常量值写入XML文件中，方便使用。这样不仅节省资源，可以直接对strings.xml文件进行修改。否则，我们需要对整个应用中的所有用到该变量的代码进行修改。