“较新”的 Model-View-Intent 架构与“较旧”的架构（如 MVC 和 MVVM）相比是否有区别？
MVI 解决了什么问题？与 MVC/MVVM 有什么相似之处？有什么区别？
关于 MVC/MVV/MVP 的 stackoverflow 上已经有类似的问题，但到目前为止还没有一个可以解释 MVI。
【问题讨论】：
标签： android model-view-controller mvvm architecture
根据我的经验，每种架构模式都是为了解决前一个忽略或尚未观察到的特定问题而发明的。
MVC - 模型视图控制器
在 UI 应用程序中，将数据渲染到屏幕或业务逻辑并将它们绑定在一起的职责起初并不清楚。所以 MVC 来将这些职责定义为三个组件，每个组件都有一个目的，图片描述了这三个组件之间的关系。
View - 是具有所有属性的 UI 组件，例如颜色、形状、侦听点击事件的工具等。
模型 - 是定义业务逻辑的组件，您希望视图呈现并相应地表现。
控制器 - 是更改模型的人，因此如果视图有一个名称（例如要保存），视图会将其传递给控制器，然后控制器使用正确的操作来操作模型。
MVP - 模型视图展示器
MVC 的问题是这三个组件之间存在很大的耦合，如果你想改变视图调用，它将需要你更新控制器和模型。 从 MVC 图片中可以清楚地看出，这三个组件之间的关系非常紧密，如果没有另一个组件，您将无法替换其中一个组件。 所以MVP通过分离模型和视图来为之前的问题提供更干净的解决方案，通过Presenter保持它们之间的交互，Presenter是每个视图和模型调用的中间人。 所以如果你想保存一个最喜欢的电影列表，View 监听用户 (*) 动作，然后调用更新模型的 Presenter 函数，然后模型告诉 Presenter 是否成功，Presenter 告诉 View 显示正确的信息。
MVVM - 模型视图视图模型
随着响应式范式的兴起，很明显，我们可以通过观察变化并在其上表现来在 UI 应用程序中提供更多独立的关注点。 所以例如有一个点击需要调用一个api来获取最新的电视节目。
这个视图点击将在 ViewModel 上被观察到，ViewModel 与模型交互以获取数据，最后 ViewModel 使用其他观察者将这些数据发布到视图上..
因此，简而言之，View 观察 ViewModel 以获取 UI 更新，而 ViewModel 观察 View 以使用 Model 调用正确的操作。观察者模式已经证明了他在解耦逻辑方面的价值，所以这里你可以使用一个新的模式。
所以在谈到最流行的架构模式之后，每个人都试图将 UI 代码与业务代码解耦。但是以前的模式并不限制同时更新具有不同状态的 UI。
如果您遇到与加载相关的问题并同时显示错误消息，您将理解我在说什么，因此要保持 UI 状态，您必须付出额外的努力查看您编写的内容错误导致此类问题。
MVI - 模型视图意图
MVI 基于称为有限状态机 的旧思想，任何系统或组件都具有可预测性，状态集是有限状态机。 在 MVI 中，对 UI 的任何更新都是由新状态定义的，您可能会发现这是压倒性的，但想象一下每次 UI 更改时您都有一个屏幕截图，这就是状态。您现在可以调试、测试、重现状态问题。
如何做到这一点，这就是 MVI 的实践。 任何用户与 UI 的交互，在 MVI 中由 Intent 定义，Intent 是用户从这个动作中需要的，它可以为电影加注星标，刷新屏幕，甚至可以打开屏幕，在这种情况下，Intent 是在屏幕上显示所有必需数据的初始意图。
哪个组件让这些 Intents 根据它们采取行动，您定义的内容......您可以使用 Presenter 或 ViewModel，没关系，MVI 与其说是使用新的中间组件，不如说是一种实践。
我将继续使用 ViewModel，ViewModel 将获取这些意图，决定调用哪个用例（模型行为）。
所有用例都通过 ViewModel 中的 Summer 函数传递，该函数决定需要反映到 View 的状态，它也为您提供先前的状态，因此您有先前和新的状态来更新屏幕，这减少了渲染更新，而 View 仅获取更新自身的新提示。
最后MVI是单向流，以View开始，以View结束。
...视图 -> ViewModel/Presenter -> 模型 -> 视图 -> ...
MVI 在管理状态的方式上有所不同，它结合了多种想法来构建更稳定、可测试的应用程序。
【讨论】：
这里有一个非常好的细分：https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/。 MVI 的核心是采用 MVVM（无状态 UI 状态）的思想，分离业务逻辑和模型，并将响应式框架置于其之上。使事物成为事件流而不是离散动作，使接收元素成为转换流的消费者而不是表示元素，并使状态成为只读的、一次性的东西，以非常结构化的方式显式地对其进行操作。
这要求您采用功能性方法来编写应用程序，尤其是 UI/View 部分。状态不会被修改，新状态是根据意图和一系列用例计算出来的。这在这里得到了很好的解释：https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a。
它旨在解决现代 UI 应用程序日益复杂的问题，这些应用程序具有大量需要显式管理的客户端状态。大多数有经验的程序员都知道，最复杂的故障来自以意想不到的方式被修改的状态。这种状态操作可能会导致您的应用程序无法处理的“无效”状态，这实际上是一个崩溃的应用程序。 MVI 解决了这个问题，通过使状态转换明确且结构严谨，使它们系统永远不会进入无效状态，并且状态总是可以理解的。
【讨论】：