我当前的MVVM android应用程序体系结构的建议

编程问答 2022-08-16

问题描述

我有将Java用于后端Web应用程序的经验，我试图从某种意义上说出MVVM体系结构的布局，但我不能停止思考Java Services，ServicesImpl，Controllers等。 ..

这是到目前为止我的android应用ui的结构：

Main activity ---> Fragment -> SubFragment
               |-> Fragment2 -> SubFragment2
               |-> etc...

足够简单，对吧？

但是就是这样。我既没有使用服务，也没有使用viewmodels（所以我想那不是MVVM结构，所以哈哈）。

所有逻辑均在Main Activity中针对全局内容编写，每个片段也具有其自己的逻辑。而且开始变得凌乱，我一直在避免让这个问题太过笑。

所以我有4个问题：

Q1）可以在片段类中编写逻辑吗？即MyFragment使用Firestore文档加载RV。在我的Java后端应用程序中，我总是使用服务和东西，并且代码仍然干净很多，但是在Android中，就像我上面所说的那样，它开始变得混乱，因为在MyFragment中我需要适配器，ViewHolder和多个查询，方法，因为我已经实现了一些过滤器。而且由于这些过滤器分别是另一个RV，所以我需要另一个适配器，另一个ViewHolder，以及……你明白我的意思了。对于我的App的早期版本，我将片段与适配器分开，创建了“ MyFragmentAdapter.kt”文件。您是否认为这样做是一个很好的解决方案？还是所有这些都应该放入viewmodel中？

Q2）到目前为止，我没有使用viewmodel，因为如果需要持久存储数据，则可以将这些数据放入Main Activity中。主要活动永不消亡，因此片段数据也永不消亡。您认为这是一个好习惯吗？

Q3）在查看开源android应用程序时，我发现没有包含services文件夹的结构，对我来说这实际上是一个给定的文件夹。为什么呢？

Q4）我项目中的文件夹的布局如下：

.project.login -> some activities with barely any logic
        .models -> just pojos
        .utils -> some utils.kt
        .ui -> recipes (folder) -> bunch of fragments with lots of logic
            -> news (folder) -> more fragments with lots of logic

您要在此结构中添加一些内容吗？

解决方法

我将尝试尽可能简单地回答。如果它适合您（您的示例），则可以。就那么简单。在这个世界上没有错误/错误的答案，最好的拱门，图案等，可以制作android应用。甚至更大的IT公司也遵循他们自己的设计模式，有些开发人员喜欢它，有些则不喜欢。无论如何，回到您的问题：

  1. 仅考虑片段和活动来负责UI逻辑。即加载视图，更改视图属性（按钮颜色，可见性等），显示这些视图上的数据等（从VM获取）。 MyFragmentAdapter->是的，使用ViewHolder创建单独的适配器类。我什至承担单个类的责任，即单独的ViewHolder类。 还是所有这些都应该放入ViewModel？->不，ViewModel不包含对视图的引用！它只保存数据并与ui通信！

  2. 您认为这是一个好习惯吗？如果您正在研究VM，那么这不是一个好主意。正如我上面所说的，Fragment（和Activity）仅负责UI逻辑。在VM中，启动查询，REST Api调用等，然后将该数据发送到UI。

主活动永远不会消失，因此片段数据也不会消失。->是，但是VM的主要MAGIC是，它“生存”了配置更改。重新创建活动时，VM是“相同的”，并保留在UI上显示所需的所有数据。

  1. 服务不包含UI，不需要ViewModels。

  2. 好的，但是我会考虑每个功能模块都有自己的逻辑。例如：配方-> ui->片段，适配器，视图模型，di（依赖项），数据（api，存储库），域（用例）

,

我不会考虑你在做什么。

无论您遵循MVVM，MVP，MVC还是其他方式，其想法都是将您的应用程序分离为至少两个不同的层：UI和逻辑。

简而言之，这意味着在活动或片段中不做任何逻辑。

在MVVM中，所有逻辑都应放在ViewModels中。任何人都不应参与活动或片段。活动和片段应该纯粹通过观察ViewModel中的LiveData字段来更新。 LiveData不是严格必需的，但是应该使用一些观察者模式。目的是使您的观点尽可能愚蠢。具有数据驱动的UI。而且您的逻辑应该对平台一无所知，甚至不应该知道这是Android。

一些好处是：

  1. 能够对所有内容进行单元测试（许多开发人员不了解此功能的重要性）
  2. 解耦后，无需更改逻辑即可更改UI，反之亦然
  3. 可移植性，可以采用相同的逻辑代码并将其放在另一个平台或另一个应用程序中
  4. 更干净的代码，更少的意大利面条，更小的文件，遵循SOLID原则，更易于阅读，调试，重构，修改等。
androidandroiddirectory-structurejavajavakotlinkotlin