在 MVVM 中,ViewModel 是否总是必需的?

In MVVM, is the ViewModel always necessary?

我是制作 android 应用程序、Kotlin 的新手,我只是想了解 MVVM 设计模式。

我正在尝试制作一个登录屏幕,同时与我团队的现有代码很好地集成。让登录屏幕工作顺利,直到我注意到我 运行 进入了未初始化的 lateinit vars 的生命周期问题(即使代码肯定 运行 初始化语句),如 SharedPreferences 或用户名和密码字段等等

在阅读了更多关于 MVVM 的内容之后,我相信我正在学习的现有代码(其中包含 ViewModel 中的 Context、Fragment 和 View 等的 lateinit vars)存在根本性缺陷并且无法解耦 ViewModel来自视图生命周期。

然而这让我很困惑。据我了解,ViewModel 应该包含业务逻辑和我们希望在配置更改后继续存在的任何数据。另一方面,LoginFragment 应仅包含 UI 和 OS 交互,例如显示视图或捕获输入。

LoginViewModel 仅包含 fragment_login.xml 和 SharedPreferences 元素之间的代码接口,或记录错误:

resetFields(): empties the fields to blank
onLoginButtonClicked(): just calls the Retrofit function to POST the username/password a server for authentication
onLoginSuccessful(): saves the data to SharedPreferences
onLoginUnsuccessful(): changes the field's error message and logs the error

因为我在 xml 元素上使用了 DataBinding,所以 nothing(据我所知)需要独立于生命周期(或者更确切地说,有几件事需要访问上下文或片段!)。

解决这个问题的正确方法是什么?目前我认为 ViewModel 根本不应该存在并且所有功能(其中很少)实际上应该只在 LoginFragment 中)。我正在考虑接下来学习和使用 LiveData,但我看不出在这种情况下 LiveData 或 ViewModel 有何必要。

任何架构模式的主要目标都是实现解耦、单一职责和限制反模式,准确地说代码应该更具可读性、可扩展性和易测试性。 我知道在某些情况下,使用这种模式对于您的用例来说似乎是多余的,但在开发一个简单的功能时,请始终牢记扩展性。这将带来长期回报,并帮助同行更好地理解和隔离代码。

在Android中,永远记住视图或UI(Activity/Fragment)应该尽可能地愚蠢,他们的唯一职责应该是倾听用户的触摸和显示数据,通过这样做,您可以在不依赖 Android 框架的情况下单独测试所有逻辑。

MVVM 是这样设计的模式,牢记 Android 的痛点,在需要时使用它不会造成任何伤害,即使是简单的任务,例如将数据存储到首选项,在显示之前对数据进行微小的转换.假设您有一个静态页面,它只使用 String 显示静态数据,没有其他任何内容,那么您可以避免使用 ViewModels。

MVVM 模式不会强制您对每个 Fragment/Activity 使用 ViewModel,它建议在需要时作为最佳实践使用它,ViewModel 只是一个持久保存配置更改的数据持有者。