在 MVVM 中，是否总是需要 ViewModel？

如何解决在 MVVM 中，是否总是需要 ViewModel？

我刚开始制作 Android 应用和 Kotlin，只是想了解 MVVM 设计模式。

我正在尝试制作登录屏幕，同时也与我团队的现有代码很好地集成。使登录屏幕运行良好，直到我注意到我遇到了未初始化的 Lateinit 变量（即使代码确实运行了初始化语句）（如 SharedPreferences 或用户名和密码字段等）的生命周期问题。

在阅读更多关于 MVVM 的内容后，我相信我正在学习的现有代码（其中包含用于上下文、片段和 ViewModel 中的视图等的后期初始化变量）存在根本性的缺陷，并且无法将 ViewModel 与查看生命周期。

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

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，没有（据我所知）需要独立于生命周期（或者更确切地说，有几件事需要访问上下文或片段!).

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

解决方法

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

在 Android 中，始终记住视图或 UI（活动/片段）应该尽可能愚蠢，它们的唯一职责应该是监听用户触摸并显示数据，通过这样做，您可以隔离地测试所有逻辑，而无需依赖Android框架。

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

MVVM 模式并不强制您对每个 Fragment/Activity 都使用 ViewModel，它建议在需要时使用它作为最佳实践，ViewModel 只是一个数据持有者，可以持久化配置更改。