MVI 与 MVC 和 MVVM 相比有什么区别

Question

与 MVC 和 MVVM 等“旧”架构相比，“较新​​”的 Model-View-Intent 架构之间有什么区别吗？

MVI 解决什么问题？与 MVC/MVVM 有什么相似之处？有什么区别？

在 MVC/MVV/MVP 的 stackoverflow 上已经有类似的问题，但到目前为止还没有解释 MVI。

MVC 和 MVVM 有什么区别？

什么是 MVP 和 MVC，有什么区别？

Answer 1

根据我的经验，每种架构模式都是为了解决前一个忽略或尚未观察到的特定问题而发明的。

MVC - 模型视图控制器

在 UI 应用程序中，将数据渲染到屏幕或业务逻辑并将它们绑定在一起的责任起初并不明确。所以MVC来将这些职责定义为三个组件，每个组件都有一个目的，图片描述了这三个组件之间的关系。

视图 - 是具有所有属性的 UI 组件，如颜色、形状、侦听点击事件的工具等。

模型 - 是定义您希望视图呈现和相应行为的业务逻辑的组件。

控制器 - 是改变模型的人，所以如果视图有一个名称，例如要保存，视图将它传递给控制器​​，然后控制器用正确的动作操纵模型。

MVP - 模型视图演示者

MVC 的问题是三个组件之间存在很大的耦合，如果要更改视图调用，则需要更新控制器和模型。从 MVC 图中可以清楚地看出，三个组件之间的关系非常紧密，如果没有另一个组件，您无法替换其中一个组件。所以MVP通过分离Model和View来为之前的问题提供一个更干净的解决方案，通过Presenter保持它们之间的交互，Presenter是每个视图和模型调用的中间人。所以如果你想保存一个最喜欢的电影列表，View 听用户 (*) 动作，然后调用更新模型的演示者函数，然后模型告诉演示者是否成功，演示者告诉视图显示正确的消息。

MVVM - 模型视图视图模型

随着响应式范式的兴起，很明显，我们可以通过观察变化并对其进行行为来在 UI 应用程序中提供更多独立的关注点。例如，在视图中单击需要调用 api 以获取最新的电视节目。

此视图单击将在 ViewModel 处观察到，ViewModel 与模型交互以获取数据，最后 ViewModel 使用其他观察者将这些数据发布到视图上..

所以简而言之，View 观察 ViewModel 以获取 UI 更新，而 ViewModel 观察 View 以对模型调用正确的操作。观察者模式已经证明了他在解耦逻辑方面的价值，所以这里是一个新的模式。

所以在讲完最流行的架构模式之后，每个人都试图将 UI 代码与业务代码解耦。但是之前的模式并没有限制同时更新不同状态的 UI。

如果您遇到与加载相关的问题并同时显示错误消息，您就会明白我在说什么，因此为了保持 UI 状态，您必须付出额外的努力来查看您写错了什么导致这些问题种问题。

MVI - 模型视图意图

MVI 基于一个叫做有限状态机的古老思想，任何系统或组件都具有可预测性，状态集就是一个有限状态机。在 MVI 中，对 UI 的任何更新都由新状态定义，您可能会发现这是压倒性的，但是想象一下每次 UI 更改时都有一个屏幕截图，这就是状态。您现在可以调试、测试、重现状态问题。

如何实现这一点，这就是实践中的 MVI。 任何用户与 UI 的交互，都是由Intent在 MVI 中定义的，Intent 是用户从这个动作中需要的东西，它可以是明星电影，刷新屏幕，甚至可以是打开屏幕，在这种情况下，Intent 是显示带有所有必需数据的屏幕的初始意图。

哪个组件让这些 Intent 根据它们采取行动，您定义的内容……您可以使用 Presenter 或 ViewModel，没关系，MVI 与其说是使用新的中间组件，不如说是一种实践。

我将继续使用 ViewModel，ViewModel 将获得这些意图，决定调用哪个用例（模型行为）。

所有用例都通过 ViewModel 中的 sum 函数，它决定需要反映到 View 的状态，它也为您提供以前的状态，因此您可以使用以前的和新的状态来更新屏幕，从而减少渲染更新，而 View 仅获取更新自身的新提示。

最后MVI是单向流，从View开始，到View结束。

... 视图 -> ViewModel/Presenter -> 模型 -> 视图 -> ...

MVI 在管理状态的方式上有所不同，它结合了多种想法来构建更稳定、可测试的应用程序。

Answer 2

一个非常好的细分在这里：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 通过使状态转换明确且精心构造来解决此问题，以便它们的系统永远不会进入无效状态，并且状态始终是可以理解的。