创建应用程序时部分应用模式（Android MVVM 架构组件）是否错误？答案

【问题标题】：Is it wrong to apply partially a pattern (Android MVVM Architecture Components) when creating an application?创建应用程序时部分应用模式（Android MVVM 架构组件）是否错误？
【发布时间】：2020-11-06 22:53:43
【问题描述】：

我有一个大型应用程序：

一些片段需要显示通过蓝牙接收到的实时数据（使用前台服务来保持与健康设备的连接）。
一些显示存储数据的片段 - 可能需要访问存储库（因此，使用 MVVM 架构组件模式很好，甚至推荐使用）。

我的问题很简单：

是否正确（从架构的角度/应用程序设计）不使用流程：View-ViewModel-Repo-DB/Cloud 访问，对于整体应用？ - 仅将 Android 模式应用于那些显示存储数据的片段/活动。

我问这个，只要显示实时数据（不存储在持久存储中，而是由服务广播）不会折叠在 MVVM 模式上：（什么的回购？我没有 2-3- 4-5个数据源来管理它们；ViewModel是什么？）我可以只拥有几个 LiveData 对象 - 在 Singleton 类中 - 由服务更新/或者服务可以发送“实时”广播（因此活动只是绑定到服务或观察 Singleton 类中的一些 LiveData 对象），没关系）。

这个问题背后的想法是前台服务是数据源，而不是持久数据。如果将 Android 的 MVVM 设计应用于整个应用程序，就会出现一个额外的问题：

前台服务“放置”在this 图中的什么位置？它是一个应用组件，因此它应该与 Activity/Fragment 处于同一级别。另一方面，它是数据的来源。（因此，它应该放在 Repository 下）。

另外，我有一些 UI 和服务使用的 SharedPref，例如：

ALERT_HEART_RATE - 当收到的值 >= ALERT_HEART_RATE 时，服务会提醒用户； - 活动显示此值/提供更改此值的可能性。

谢谢。

【问题讨论】：

我可能无法准确回答您的问题，因为您的问题对我来说微不足道，尽管我可以肯定地传达一件事，即使对于您的前台服务模式，您仍然可以遵循 MVVM 模式，您的服务现在更新 repo 而不是直接更新 UI 并且您的 UI 现在通过 viewmodel-repo 请求实时数据。查看我的这个答案：stackoverflow.com/a/53552240/10271334

标签： android android-service android-livedata android-architecture-components android-mvvm

【解决方案1】：

数据源是否持久并不重要... 与动态数据的唯一区别是，双向数据绑定没有意义，因为数据源是只读的。

【讨论】：

感谢您的回答。问题更复杂：该服务还可以访问一些也显示在 UI 中的 SharedPref 变量。所以，整个应用背后的逻辑主要在前台服务内部。例如，我需要存储服务和 UI 都使用的 ALERT_HEART_RATE（服务使用它来提醒用户（当收到的值大于 ALERT_HEART_RATE 时，Activity 显示该值 - 这需要与服务使用的值同步）。我会更新我的问题，也许会。
对新应用使用DataStore 而不是SharedPreferences ...原则上，这与R/O web 服务没有太大区别。虽然前台服务不接触视图，但它可以有自己的逻辑。 ViewModel 是用来控制视图的。
是的，你是对的。服务有它自己的逻辑——我的“问题”是将服务与用户界面“链接”的最佳方式，只要隐含许多因素（如 DataStore/SharedPref）。所以你建议坚持使用 MVVM 模式（拥有一个可以访问前台服务的 Repo）？
该服务可以将测量值广播到应用程序......并且没有对错，而该服务由于职责分离而不会尝试访问视图。类似的东西：Service > Broadcast > LiveData > ViewModel > View。
你所说的，是指在 ViewModel 中使用接收器（为了更新 LiveData），并将存储库留在外面（没有 Repo）。这里出现了一个问题：同一个应用程序的两个部分有 2 种架构模式：1. 由您指定的，在“实时”片段/活动中，以及 2.MVVM Android 的模式在那些访问的片段中数据库数据。这样好吗？（不在整个应用程序中应用相同的模式）