《MVP模式》与《UI更新》的偶遇

      做了3年多的javaEE，现在正在努力转型Android开发的路上 , 在阅读别人的项目代码时，我发现他们或多或少都是把视图和逻辑代码习惯性的写Activity类中，又或者在一个业务类中写很多的静态方法，然后传一堆的view、context,handler传过去，然后把view层的东西又放到业务类里写，作为一个习惯MVC的JavaEEer来说，实在不能忍，刚在看书的过程中（*《android开发必知的50个诀窍》），有一章介绍了Android开发中常用的MVP模式，作为一个处女座，我觉得有必要试一试。

下面直接贴代码说明：Github(https://github.com/fgnna/aidaban)

包路径：

- view  视图层，activity/Fragment等等

- presenter  主导器，负责视图层与数据层之间的业务调用
        + modelInterface  model层接口，定义model需要实现的方法,如获取一组数据
        + viewInterface     view层接口，如更新视图中的一个textview。

- model 模型层，我叫它做数据层

下面我总共有三个实体类和两个接口类

先说主导器：

ChoicePresenter: 主导器里只做一件事，在实例化后，从model中获取第一页的数据，然后通知view作出更并把数据传递过去

public ChoicePresenter(Context context, ChoiceViewInterface choiceViewInterface)
	{
		this.mContext = context;
		this.mChoiceViewInterface = choiceViewInterface;
		this.mChoiceModelInterface = new ChoiceModel();
		this.init();
	}
	
	//初始化步骤
	private void init()
	{
		new AsyncTask(){
			@Override
			protected Object doInBackground(Object... params)
			{
				//初始化第一页的数据
				mChoiceViewInterface.initPageData( mChoiceModelInterface.getInitPageData(mContext) );
				return null;
			}
		}.execute(10);
	}

ChoiceViewInterface: 定义view虽要做的事情

/**
	 * 初始化第一页的数据
	 * @param list 第一页的数据
	 */
	public void initPageData(List<ChoiceBean> list);

ChoiceModelInterface: 定义model需要做的事情

        /**
	 * 获取首页数据集
	 * 
	 * @param context
	 * @return
	 */
	public List<ChoiceBean> getInitPageData(Context context);

ChoiceModel implements ChoiceModelInterface:  model实现类，作用不多说了

@Override
	public List<ChoiceBean> getInitPageData(Context context)
	{
		List<ChoiceBean> data = new ArrayList<ChoiceBean>();
                //..............................
		return data;
	}

ViewpagerChoiceFragment  implements ChoiceViewInterface :  view层，需要实现ChoiceViewInterface接口并完成接口方法

@Override
	public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
	{
		// 保证最后两个参数不被参改，即必须这样传参，（这是官方注释的原话，不知道我理解是否正确）
		mListView= (ListView) inflater.inflate(R.layout.viewpager_choice, container, false);
		
		this.mChoicePresenter = new ChoicePresenter(getActivity().getApplicationContext(),this);
		
		return mListView;
	}
	
	@Override
	public void initPageData(final List<ChoiceBean> list)
	{
		mChoiceListViewAdapter = new ChoiceListViewAdapter(getActivity().getApplicationContext(),list,mChoicePresenter);
		
		handler.post(new Runnable() {
		    public void run() {
		    	mListView.setAdapter(mChoiceListViewAdapter );
		    }
		  });
	}

    现在可以着重的来看 ViewpagerChoiceFragment 这个view层的类，在onCreate中，首先实例化一个 主导器，然后通过构造方法传递到 主导器中，之后的所有业务逻辑都交给 主导器来完成，实现了视图与业务逻辑的分离。

    然后主导器知道在这个view初始化时，需要做两件事：获取第一页数据和通知View更新并把数据传递给view，而这时候，view只需要知道完成initPageData(final List<ChoiceBean> list)这个方法，目的很确定，就是把收到的数据更新到view控件中。

    在这个过程中，主导器负责起整个view和model的中间环节的内容，定义model要做些什么并告诉view什么时候需要更新，view和model都独立的干着自己的活，view不需要知道怎么获取数据，model只管获取数据并返回果结果，这样就现实了层次分离，单一职责，并而测试和维护代码能够更加容易，特别适合多人合作开发的情况。

    最后补充一点就是，像动作监听事件这类接口，也应该在主导器中实现，而不是在view层。

转载于:https://my.oschina.net/u/1392566/blog/398653