nofyso

草稿-1

草稿

是的，最近刚刚开始研究这玩意，由于写在纸上还是太过于凌乱了，所以写到了这里
o((>ω< ))o

各个层级的分工

Data层

这一层用来存放RepositoryImpl、DTO这类东西，处理一些最底层的数据交互，例如数据持久化的细节
一些网络的基础操作，Retrofit、本地文件的处理在这里进行

Domain层

这一层处理具体的业务逻辑，例如UseCase，Entity，以及AbstractRepository
Repository的选择、各种DataSource的分流在这里进行

Presentation层

这一层存放UI界面，处理UI和Domain层的关系
StateNotifier存放在这里，他接受UI的请求，调用Domain层的UseCase，并更新StateNotifier；注意：StateNotifier本身不处理大量业务逻辑 （可能仅仅作为“薄层”存在？天哪，这是什么奇奇怪怪的名词…）

具体应用

老实说，我现在对于现在的局面缺乏掌控……我想我应该尽可能……嗯，尽可能调整并且审视一下当前的局面……

Data层

在这层，我并没有存放任何DTO，因为获取到的持久化数据也好，从网络中拉取到的东西也罢，都可以完全等同于Domain层的Entity，并且给他们加了JSON序列化之后，情况好了非常多
在这一层，我存放了在Domain层定义的AbstractSchool的不同学校的实现类，而这些实现类内部有各种的诸如Retrofit的东西啊、TensorFlow的东西啊，各种奇奇怪怪的，却又接近比较底层的东西
由于配置了DI，Domain层可以很轻松地拿到这层的RepositoryImpl实例
关于这层，有几个问题：

  1. 在这层，需要处理不同数据源的处理和整合，所以数据持久化的工作理应放在这层——这点我之前没有搞懂，导致现在的结构十分混乱，天哪——所以，数据持久化和数据源的选择的具体操作应该放在Data层，这点我可能要想想怎么重构……
    一种可行（？）的方法是：将数据抽象成Stream，先从本地拉取数据yield出去，然后再从网络上拉取最新的消息，这样又会造成一些问题：其中一个问题是如何处理刷新逻辑的问题（如果我要手动触发数据刷新，例如强行从网络拉取数据，或者我想控制拉取数据的时间，例如我想先从网络预载数据，然后立即持久化它，用户看到的永远是本地的数据，这种应该怎么实现呢？我不想让数据在被看到的时候才开始从网络加载）
    （或者还有一种方法：UI的Notifier访问的UseCase仅仅拉取本地信息，新建一个新的管理刷新的Notifier和UseCase，由UI载入时手动触发刷新，刷新后，重建对应的Notifier，使UI做出更改，这样就不需要使用Stream）
    好吧，这个问题我大概知道了，留到下一章解决

Domain层

这层相对重要一点……或者说，它是最重要的也不为过，目前很多的疑问出现在这层
首先，我创建的UseCase太多了，多到已经有点到了过度设计的程度，我应该考虑删掉一点……或者说，删掉很多
之后再说吧

Presentation层

除了Notifier以外，没啥要注意的

重构

正如你（或者说“我”）所见，这个项目需要一次重构，包括但不限于重建现有的架构
首先是在上一章的Data层提到的问题：我现在打算采用第二种解决方案：

  • 所有诸如ClassTableNotifier此类直接获取数据的Notifier不再获取联网数据，而仅使用本地数据
  • 创建一个RefreshNotifier，它维护了当前刷新的状态，并提供刷新需用的方法
  • 当数据需要刷新时，UI调用RefreshNotifier的刷新方法，RefreshNotifier负责调用网络操作的API（AbstractRepository）然后RefreshNotifier重建其它Notifier，使watch它们的UI重建
  • 对对对，再像旧项目一样抽象一下刷新流程

一些可能的问题：

  • 如果用户想要选择拉取的日期，而不是默认值的话，数据又要怎么流呢？
  • RefreshNotifier的业务逻辑会不会太多了……？
  • 应该……没多大问题了……吧？

以及，还有一个问题：登录所需数据（账号密码这类的）持久化数据该由谁管理？
目前的看法：

  • 目前认为，应该由Data层管理
  • Domain层传入一次登录数据后，以后直接调用Data层的登录方法，直接获取登录结果
  • 所以，Domain层现在不干涉这些持久化数据的存储
  • 而Data层管理这些登录相关的持久化数据，例如在Domain层传入数据，登录成功后，Data层直接存放这些数据，而不是像之前那样，Domain层读取和存放持久化数据，Data层一直依赖于Domain层传入的数据
  • 之前的方法其实暴露了这个问题：原本Data层的登录仅仅依赖于登录持久化数据，以及初次从Domain层传入的登录数据，而我将前者的依赖关系复杂化了（Domain–完全依赖->Data），这是十分愚蠢的，改成现在这样（Domain–部分依赖->Data(自己依赖自己)），应该会更加合理一点

好了，再写一个跑不起来的原型： 

1
2
3
4
5
6
class RefreshNotifier extends StateNotifier<RefreshState>{}
class RefreshState{
  bool isRefreshing;
  int refreshPhase;//TODO
}
//想象这里有Provider

我到底在和谁说话啊
不管啦