浅谈Android中的架构模式——MVC（一）

  平常我们Android开发时，特别是刚开始学习的时候总会一股脑地把所有代码都放到Activity/Fragment里编写，虽然能实现功能，但是在业务逐渐多起来的时候，甚至说没有繁杂业务，有繁杂操作的时候，整个Activity/Fragment的代码体积就会越来越庞大，也难以去维护，甚至你看回自己的代码都得花费老半天时间。

  那么这里我就浅谈一下如何将一些常用的框架应用到Android开发中，为我们的开发及维护提供良好的编程环境。

  首先谈下MVC框架。

MVC框架

  

  我们要明确几点，首先MVC框架里分别是什么？

  Model层：独立的业务模块，比如联网、访问数据库或者一些特定的业务操作；一般会有对应生成的接口供外部实现。

  View层：视图层，是用户能看到并进行交互的模块，一般对应Android里的xml文件。

  Controller层：负责接收用户交互操作后的逻辑控制，一般在Android里对应的是Activity/Fragment等组件。

  道理我都懂，可是如何结合具体实例情况进行编程呢？

  那接下来就以登录模块为例，来分析一下MVC各个模块是如何工作的：

1. 用户在输入用户名和密码以及点击登录的操作这一步是属于View层的工作模块。
2. 在用户点击登录以后，会由对应的Controller层来通知执行相应的业务。这里通知的是登录业务，那么就会去调用登录模块。
3. 登录模块的Model层在接收到Controller的指令后，会执行对应的方法，来完成操作。完成后一般会通过接口回调给外部，例如这里会告知View层，登录成功/失败，那么View层就会执行对应的UI显示。

  实现效果如下：

  Talk is cheap, show me the code. 那么接下来我们就开始分析一下代码。

  这是我的mvc模块结构：

  

  首先来看下Model层的实现，我这里是模拟了用户的联网耗时操作，并且随机返回登录成功/失败的方案。

class LoginModel {
    fun login(username: String, pwd: String, callback: NetCallback) {
        Thread(Runnable {
            // 模拟登录
            Thread.sleep(2 * 1000L)
            val ran = Random.nextBoolean()
            if (ran) {
                callback.onSuccess(LoginResponseBean(200, username + "login success"))
            } else {
                callback.onError("login error")
            }
        }).start()
    }
}

// 相应的接口
interface NetCallback {
    fun onSuccess(res: LoginResponseBean)

    fun onError(errMsg: String?)
}

  至于View层，其实就是一个布局xml文件，我接下来的博客也会用到这个布局layout_login.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <EditText
        android:id="@+id/et_username"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="请输入用户名"
        android:layout_marginTop="20dp"
        app:layout_constraintTop_toTopOf="parent" />

    <EditText
        android:id="@+id/et_pwd"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="请输入密码"
        android:layout_marginTop="20dp"
        app:layout_constraintTop_toBottomOf="@id/et_username" />

    <Button
        android:id="@+id/btn_login"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="登录"
        android:layout_marginTop="20dp"
        app:layout_constraintTop_toBottomOf="@id/et_pwd"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent" />

    <ProgressBar
        android:id="@+id/progress_bar"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:visibility="gone"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent" />

    <TextView
        android:id="@+id/fragment_tag"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textSize="23dp"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

  Controller层，也就是Activity/Fragment的实现也相对简单，但其实感觉很多开发者包括我自己，一开始接触的时候总认为Activity和Fragment这种组件其实就是View，但在MVC框架中，他们还真不是。。毕竟是充当逻辑控制者的身份，所以执行的更多是Controller的工作。

class MVCFragment: Fragment() {
    companion object {
        private const val TAG = "MVCFragment"
    }

    private lateinit var mRootView: View
    private lateinit var mEtUsername: EditText
    private lateinit var mEtPwd: EditText
    private lateinit var mBtnLogin: Button
    private lateinit var mProgressBar: ProgressBar
    private lateinit var mFragmentTag: TextView

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        mRootView = inflater.inflate(R.layout.layout_login, container, false)
        initViews()
        return mRootView
    }

    private fun initViews() {
        mEtUsername = mRootView.findViewById(R.id.et_username)
        mEtPwd = mRootView.findViewById(R.id.et_pwd)
        mBtnLogin = mRootView.findViewById(R.id.btn_login)
        mProgressBar = mRootView.findViewById(R.id.progress_bar)
        mFragmentTag = mRootView.findViewById(R.id.fragment_tag)

        mFragmentTag.text = TAG

        mBtnLogin.setOnClickListener {
            if (paramChecked()) {
                mProgressBar.visibility = View.VISIBLE
                // 这里开始调用Model层的业务
                LoginModel().login(mEtUsername.text.toString(), mEtPwd.text.toString(), object : NetCallback {
                    override fun onSuccess(res: LoginResponseBean) {
                        // 接口回调 操作View
                        activity?.runOnUiThread {
                            mProgressBar.visibility = View.GONE
                            Toast.makeText(this@MVCFragment.context, res.msg, Toast.LENGTH_SHORT).show()
                        }
                    }

                    override fun onError(errMsg: String?) {
                        activity?.runOnUiThread {
                            mProgressBar.visibility = View.GONE
                            Toast.makeText(this@MVCFragment.context, errMsg, Toast.LENGTH_SHORT).show()
                        }
                    }
                })
            } else {
                Toast.makeText(context, "请先输入完整", Toast.LENGTH_SHORT).show()
            }
        }
    }

    private fun paramChecked(): Boolean {
        return mEtUsername.text.toString().isNotEmpty() && mEtPwd.text.toString().isNotEmpty()
    }
}

  至此，这个MVC框架的应用就完成了，这里完成了一个登录业务的编写，其他业务也可以类似地写。当然模式并不是固定的，只是编程思想理解就好~

  注意一点，MVC工程并不是能完美应用在所有的工程项目里，这种框架的应用还是要实际情况实际考虑。毕竟如果业务一直扩展的话，Model和View之间的耦合就不可避免地会增大代码维护的难度，同时Controller层的逻辑代码也会一直增大，那么维护起来也是相当头疼的~

  接下来还会去浅谈分析一下MVP和MVVM的框架...