Question

我了解架构组件中的ViewModel用于存储和管理数据，因此在配置更改期间它不会丢失。

例如，我的活动与LiveData或存储数据无关。我应该仍然通过ViewModel吗？或直接实例化Repo类并调用插入方法？我希望有道理

使用ViewModel的示例

public class MainViewModel extends AndroidViewModel {
    private DataRepo dataRepo;
    private LiveData<List<Group>> groupList;
    private LiveData<List<Bill>> billList;

    public MainViewModel(Application application) {
        super(application);
        dataRepo = new DataRepo(this.getApplication));
        groupList = dataRepo.getGroup();
        billList = dataRepo.getBill();
    }

    public LiveData<List<Group>> getGroupList() {
        return groupList:
    }

    public LiveData<List<Bill>> getBillList() {
        return billList:
    }

    public void insertGroupAndMember(Group group) {
        dataRepo.insertGroupAndMember(group);
    }

    public void insertBills(List<Bill> bills) {
        dataRepo.insertBills(bills);
    }

    public List<Member> getMemberList(Group group) {
        return dataRepo.getMembers(group);
    }
}

Answer 1

以下是我建议您考虑的几点：

MVVM作为一种模式可以追溯到2000年，例如，here is Martin Fowler's article就是这个概念，而2005年，John Gossman在他的博客中宣布了这种模式。是的，它解决了Android模式实现中旋转的问题，但是没有它可以解决此问题。实际上，需要MVVM才能将演示状态与最终用户看到的视图分开。正如Wiki所说-

视图模型是视图的抽象，公开了公共属性和命令。 MVVM具有绑定程序，可以自动执行视图及其视图模型中绑定属性之间的通信，而不是MVC模式的控制器或MVP模式的演示者。视图模型已被描述为模型中数据的状态。

因此，主要是（与其根中的所有其他GUI架构模式一样）与应用程序的 view 和 domain 部分之间的抽象有关，以便它们可以独立变化，并且随后对系统进行的更改将很便宜。

实例化视图范围内的域对象及其随后被视图使用会导致视图和域对象之间的紧密耦合，这对任何系统都是不利的。另外，更改视图内部也是另一个原因，因为如果域对象的构造逻辑发生变化，则视图也必须更改。

如果ViewModel非常适合您（如我所见，在特定情况下，它的好处与您无关，因为UI不太复杂且状态为轻量级），请考虑使用较轻的重量抽象，例如MVP。因此，您将能够在应用程序中保留视图和模型之间的抽象（没有不必要的耦合），并且不必支持您无法从中受益的代码。

Answer 2

我认为您想使用ViewModel来保持UI控制器尽可能的干净。您的视图模型应调用存储库以执行简单的CRUD操作。请参见文档中的snippet，如下：

需要UI控制器还负责从数据库或网络加载数据给全班增加了膨胀。为UI分配过多的责任控制器可以产生一个试图处理所有应用程式本身的工作，而不是将工作委派给其他类别。通过这种方式向UI控制器分配过多的责任也使测试更加困难。

Android，我是否使用ViewModel执行插入或更新？

2 个答案: