一、最简单：无界面

package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        printf("hello,world\n");
    }
}

二、复杂一点点：有界面、有逻辑

1. Code Block：把UI和逻辑间放在一起，你在同一个地方可以同时维护UI和逻辑：

package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        TextView tv = new TextView(this);
        tv.setText("Hello, World!");
        setContentView(tv);
    }
}

1. Code Behind：把UI和逻辑各自分开，你可以让UI和逻辑各自做好各自的事情：

package study.android;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class HelloWorld extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.hello);
    }
}

<?xml version="1.0" encoding="utf-8"?>  
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
    android:layout_width="fill_parent"  
    android:layout_height="fill_parent"  
    android:orientation="vertical" >  
    <TextView  
        android:layout_width="fill_parent"  
        android:layout_height="wrap_content"  
        android:text="hello" />  
</LinearLayout>  

真正的分歧：
是按逻辑和UI划分地管理，还是按单界面的事务进行划分地管理

三、再复杂一点点：界面和逻辑很多，而且数据量也变大了

App从处理一件事务发展到了要处理许多事务，各事务间有包含、顺序、主次等等的关系，变得越来越复杂。因为数据与逻辑庞大了，所以数据与逻辑就分离了，然后事件和业务分离了。最终分化成如下原子:

• 界面
• 数据
• 事件
• 业务

并形成了不同的设计思想：

1. Model-View-Controller（Model-View-Controller）

MVC

MVC的一般流程是这样的：View（界面）触发事件–》Controller（业务）处理了业务，然后触发了数据更新–》Controller更新了Model的数据–》Model（带着数据）回到了View–》View更新数据

在MVC中，当你有变化的时候你需要同时维护三个对象和三个交互，这显然让事情复杂化了。而实际状况是View的界面样式往往多变，而其内在逻辑很少变化。于是MVP产生：

2. Model-View-Presenter（MVP）

MVP定义了Presenter和View之间的接口，切断了View和Model之间的调用关系，让需求可以根据已有的接口协议去各自分别独立开发，解决了界面需求变化频繁的问题。上面两图都有接口，不过接口的实现和使用细节不一样，但思想上是一致的。

• Android应用参考：浅谈Andorid开发中的MVP模式

后来又发现了比MVP更省力的方法，就是：

3. Model-View-ViewModel

ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步。数据绑定你可以认为是Observer模式或者是Publish/Subscribe模式，原理都是为了用一种统一的集中的方式实现频繁需要被实现的数据更新问题。

比起MVP，MVVM做了一件事情：直接让界面元素和model双向绑定。这样一来，View的变动，自动反映在 ViewModel，反之亦然。这样开发者就不用处理接收事件和View更新的工作，框架已经帮你做好了。

• Android应用参考：精通 Android Data Binding

参考文章：

1. 从Script到Code Blocks、Code Behind到MVC、MVP、MVVM
2. 浅谈开发中的MVVM模式及与MVP和MVC的区别