所以,我对大多数概念都有所了解,但我希望能够对某些事情有所了解.
根据我的理解,
> View层是处理UI的外层,和
框架相关的东西
>演示者是视图的直接通信器,它接受用户输入,并通过将其传递给用例层或交互器层来执行基于此的某些用例.
> Interactor执行用例,将其返回给演示者发送的回调,
> Presenter再次将此结果转换为可视化的数据结构(viewmodel),并将其传递回视图.
我没有列出关于内层如存储库的更多细节,因为我的问题与上述步骤有关
在这里,演示者是否只能充当UseCases和UI之间的中介,作为数据调度员？
是否仅使用视图模型来使用案例模型转换,反之亦然？
输入验证逻辑依赖于哪一层？可以在演示者里面吗？例如,如果我们采用注册过程的小用例,
一旦用户输入了详细信息并单击了注册按钮,并将数据发送给演示者,就好了
>如果有任何错误通知,Presenter将验证输入值
风景
>如果值正确,请将其转换为用例模型,然后执行
某个用例,一旦结果由交互者给出,
再次转换为视图模型,将其发送到视图.
第二个问题是,谁控制导航？ View或Presenter或UseCase？
谁决定下一步去哪儿？
例如 – 考虑登录过程的用例,用户将在其中输入凭据并单击“确定”.
成功登录后,
>如果未验证用户电子邮件,请转到电子邮件验证屏幕
>如果用户配置文件未完成,请设置配置文件,然后只转到主屏幕
>如果用户是新用户,则显示新的优惠屏幕,否则直接转到主屏幕
那么,谁负责在接下来的哪个屏幕上做出这些决定？它是演示者,它相应地决定和导航视图吗？或者是用例处理程序有责任告知演示者下一个状态是什么？
很抱歉提出这个问题的时间太长了,但我只是想详细说明我目前的理解.提前致谢
解决方法
Here,does the presenter have the only job of acting as a mediator
between UseCases and UI,as a data dispatcher?
是
The input validation logics rely on which layer? Can it be inside the
presenter?
验证应该依赖于业务层而不是表示,是否可以在演示者内部？确定它可以,但是如果你有多个屏幕需要类似的输入,你必须在每个演示者内重复验证逻辑吗？你可以说你可以做一个基础演示者,但这不是完美的解决方案,因为演示者应该有一个目的.
And the second question is,who controls the navigation? The View or
the Presenter or the UseCase?
你认为导航是域或演示文稿或数据层的一部分,它可能与表示层有关,但你可以在表示层中创建一个小组件,它通常控制整个导航,所以你可以使用这个组件当您决定需要其他平台并将您的活动抛弃时.你可以在你提到的样本中找到这种方法.
编辑：0
How you pass data between modules where they have different models?
你只需使用映射器,原因是使每个模块都有自己的模型或实体,因此很容易分别测试每个模块.
关于演示者和视图,假设你想要显示错误消息,演示者决定它将显示的原因,视图决定它将如何显示.
我认为用Android来理解干净的代码表示层的问题是,活动和片段不仅是视图,它们也是你的代码所处的过程和生命周期,干净的代码出现在单独的意大利面条代码上那些活动和片段.
编辑：1
最后一点,现在很明显,谷歌和那里的支持团队通过引入一套很棒的库“Architecture components”,尽可能地制作活动和片段虚拟视图.我鼓励任何人检查它们,即使你正在使用MVP,你也会发现很大的好处.
