MVP模式的一种新尝试

前言

在暑假的时候学习了一遍mvp开发模式在android中的运用。那个时候学的时候确实觉得mvp模式做安卓开发特别清晰,代码模块分的特别清楚。但是在自己写demo的时候还是把自己有点绕晕了。因为mvp模式运用了大量的接口(面向接口编程)来实现view和model层的解耦。那时候甚至连设计模式都没看,所以一下子接触这种抽象的设计模式有点不适应。虽然说google的data-binding的不断完善会导致安卓上面mvvm模式越来越火,但是我觉得设计模式嘛,学习一下没有坏处,可以提升自己的理解力。这篇博客主要讲一种mvp的一种新尝试(将activity, fragment, adapter作为presenter)。

MVP

mvp模式与mvc模式最大的差别就是,它将view层跟model实现完全解耦。所有的数据交互都在presenter层中。view,model和presenter的交互通过接口,view和model的交互通过presenter。解耦的好处就是视图层和数据层两者互不影响,所有的逻辑都在presenter中,他作为一个中间层可以给多个view来使用。完全通过接口来解耦可以提高代码维护度。

而mvc模式则是视图层可以通过control与数据层交互也可以直接跳过control和数据层直接交互。这样大多数时候会在view层里面new出model/bean的对象来。这样就把两者耦合在了一起。

传统mvp

传统的mvp模式是将activity或者fragment作为view层,将所有的逻辑代码抽出到presenter(一个java类)。这是我暑假写的一个demo源码 传统mvp demo 。

MVP模式的一种新尝试_第1张图片
mvp1.png

可以通过我的项目分包看出来,每一个类实现接口,通过接口来进行抽象解耦,以及数据交互。

一种新思想

这个思想也是通过github上面一个翻译的文章看来的。因为activity中包含着context, intent,获得系统服务等等,如果把activity作为视图层就应该避免这些业务逻辑。所以将activity仅仅作为视图层有点发挥不出他的真正价值。所以我们考虑把activity,fragment,adapter来作为presenter处理逻辑,用java类文件来作为视图层。并且这样做了之后,我感觉代码的清晰度是有提升的。这是我写的demo源码:新mvp demo 。

MVP模式的一种新尝试_第2张图片
mvp2.png

大概思路是用一个抽象类来抽出activity中必不可少的ui代码(比如setContentView()以及初始化各种控件)。然后每一个view类文件实现扩展了view层基接口的接口,这样做的目的是为了实现view和baseacitivty之间的解耦。(这个确实倒腾了很久,因为我感觉原文章的代码有问题)。之后在抽象类里面去通过presenter返回的view文件类型,用反射获得对象并进行view的渲染。然后再在presenter中去处理逻辑。看代码吧!

/**
 * Created by Zane on 15/12/5.
 * 用于抽出activity中对于ui的操作代码
 * 弄出两个抽象方法来保证生命周期同步
 */
public abstract class BasePresentActivity extends AppCompatActivity{

    protected V vu;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        try {
            vu = getVuClass().newInstance();
            vu.init(getLayoutInflater(), null);
            setContentView(vu.getView());
            onBindVu();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }

    }

    @Override
    protected void onDestroy() {
        onDestroyVu();
        vu = null;
        super.onDestroy();

    }

    protected abstract Class getVuClass();

    protected void onBindVu(){};

    protected void onDestroyVu() {};
}

首先解释这个抽象类的两个泛型。Vu是view层的基接口,代码如下:

/**
 * Created by Zane on 15/12/5.
 * view类的超类
 */
public interface Vu {
    void init(LayoutInflater inflater, ViewGroup container);
    View getView();
}

可以看到有两个方法,一个用来进行view渲染,一个是返回根视图。而泛型里面的V就是扩展了Vu的第二层接口。最后X就是实现了第二层接口的view类文件。这样做的目的就是做到解耦,防止我用传入的类文件去实例化类文件,这里应该是去实例化接口。(用X的对象去实例化V)

然后再看onBindVu()和onDestoryVu()方法,这个方法是在继承了这个抽象类的presenter里面去实现的,目的是为了达到生命周期同步。

getVuClass()方法就是要获得这个presenter对应的view类文件类型。

/**
 * Created by Zane on 15/12/5.
 * 为了使view类和present类解藕
 */
public interface VuLoginActivity extends Vu{

    Button getButtonLogin();

    Button getButtonClear();

    EditText getEditTextAccount();

    EditText getEditTextPassword();

    void clearText();

}

这就是扩展了Vu接口的第二层接口。看到我添加了几个方法。

/**
 * Created by Zane on 15/12/5.
 */
public class LoginActivityViewImpl implements VuLoginActivity{

    protected View view;
    protected Button buttonLogin;
    protected Button buttonClear;
    protected EditText account;
    protected EditText password;

    @Override
    public void init(LayoutInflater inflater, ViewGroup container) {
        view = inflater.inflate(R.layout.activity_main, container, false);
        buttonLogin = (Button)view.findViewById(R.id.button_login);
        buttonClear = (Button)view.findViewById(R.id.button_clear);
        account = (EditText)view.findViewById(R.id.account);
        password = (EditText)view.findViewById(R.id.password);
    }

    @Override
    public View getView() {
        return view;
    }

    @Override
    public Button getButtonLogin() {
        return buttonLogin;
    }

    @Override
    public Button getButtonClear() {
        return buttonClear;
    }

    @Override
    public EditText getEditTextAccount() {
        return account;
    }

    @Override
    public EditText getEditTextPassword() {
        return password;
    }

    @Override
    public void clearText() {
        account.setText("");
        password.setText("");
    }
}

这里代码也很简单啦!

public class MainActivity extends BasePresentActivity {

    @Override
    protected void onBindVu() {

        final User user = new User();

        vu.getButtonLogin().setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                String userName = vu.getEditTextAccount().getText().toString();
                String password = vu.getEditTextPassword().getText().toString();
                Toast.makeText(MainActivity.this, userName, Toast.LENGTH_SHORT).show();
                if(userName.equals(user.getUserName()) && password.equals(user.getPassword())) {
                    Intent intent = new Intent(MainActivity.this, LoginSuccessActivity.class);
                    intent.putExtra("username", userName);
                    startActivity(intent);
                }else {
                    Toast.makeText(MainActivity.this, "错误", Toast.LENGTH_SHORT).show();
                }
            }
        });

        vu.getButtonClear().setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                vu.clearText();
            }
        });
    }

    @Override
    protected void onDestroyVu() {
        super.onDestroyVu();
    }

    @Override
    protected Class getVuClass() {
        return LoginActivityViewImpl.class;
    }
}

这个就是presenter。看到我在对应的生命周期里面做了逻辑处理,并且返回他对应的view类文件。

结束语

MVP模式确实给项目维护带来了一些便捷,但是也发现,相对于小的项目会导致你的代码量迅速膨胀。所有很多人弄一些mvp的开发框架。确实我自己也想用这种新思路来倒腾一个。但是对于大型项目,这样的代码膨胀并不算什么,带来的好处绝对优于坏处。这次学习又巩固了一下我的设计模式。以一句话结尾:面对接口编程, 避免面对实现编程

未经博主同意,不得转载该篇文章

你可能感兴趣的:(MVP模式的一种新尝试)