相比于MVC和MVVM这样的“旧”架构，"新"的Model-View-Intent(MVI)架构有什么区别吗？
MVI架构解决了什么问题？与MVC/MVVM有哪些相似之处？又有哪些不同之处？
stackoverflow上已经有关于MVC/MVP/MVVM的类似问题，但还没有解释MVI的。
MVI与MVC和MVVM相比有什么区别？
35
- vuko_zrno
1
2同样类似的内容：MVC vs MVP vs MVVM使用场景 - jkdev
2个回答
86
从我的经验来看，每种架构模式都是为了解决先前被忽视或尚未观察到的特定问题而发明的。
MVC - 模型-视图-控制器
视图-是具有所有属性（如颜色，形状，工具等）以监听单击事件等的UI组件。
模型-是定义您希望视图呈现和相应行为的业务逻辑的组件。
控制器-是更改模型的组件，因此，如果视图例如有一个名称要保存，则视图将其传递给控制器，然后控制器使用正确的操作来操作模型。
MVP-模型视图展示器
MVC的问题在于三个组件之间存在很大的耦合，如果要更改视图调用，则需要更新控制器和模型。从MVC图片中可以看出，三个组件之间的关系非常紧密，不能替换其中一个组件而没有其他组件。
因此，MVP通过分离模型和视图，通过Presenter保持它们之间的交互，提供了更清晰的解决方案。Presenter是视图和模型调用的中间人。因此，如果要保存收藏电影列表，则视图侦听用户(*)操作，然后调用Presenter函数更新模型，然后模型告诉Presenter是否成功，Presenter告诉视图显示正确的消息。
此视图点击将在ViewModel中被观察到，ViewModel与Model交互以获取数据，最后ViewModel使用其他观察者将这些数据发布到视图上。
简而言之，View观察ViewModel以获取UI更新，而ViewModel观察View以使用Model调用正确的操作。观察者模式已经证明了它在解耦逻辑方面的价值，因此这里介绍了一种新的模式。
所以在讨论最流行的架构模式后，每个模式都试图将UI代码与业务代码解耦。但是先前的模式没有将更新UI与同时的不同状态绑定起来。
如果您遇到与加载出现错误消息同时显示有关的问题，您将理解我在说什么，因此为了保持UI状态，您必须做额外的努力查看您写错了什么导致这些问题。
MVI-Model View Intent
MVI基于一个叫做有限状态机的旧想法，任何系统或组件都有可预测的一组状态，是一个有限状态机。在MVI中，UI的任何更新都由新状态定义，你可以将其视为每次UI更改的截图。现在你可以调试、测试和重现状态问题了。
如何实现这一点，这就是MVI的实践。用户与UI的任何交互，在MVI中都由Intent定义，Intent是用户从这个操作中需要的内容，它可以是收藏电影、刷新屏幕，甚至可能是打开屏幕，在这种情况下，Intent是一个显示屏幕并提供所有所需数据的初始Intent。
哪个组件获取这些意图并据此采取行动，这是由您定义的...您可以使用Presenter或ViewModel，这并不重要，MVI更多是一种实践，而不是使用新的中间组件。
我将继续使用ViewModel，ViewModel将获取这些意图，决定调用哪个用例（模型行为）。
所有用例都通过ViewModel中的夏季函数，决定需要反映到View的状态，它还提供了先前的状态，因此您有先前和新状态来更新屏幕，从而减少渲染更新，并且View只获取更新自身所需的新提示。
最后，MVI是单向流，它始于View并以View结束。
MVI在状态管理方面与众不同，它是几种构建更稳定、可测试应用程序的思想的组合。
{{... View -> ViewModel/Presenter -> Model -> View -> ...}}
MVC - 模型-视图-控制器
视图-是具有所有属性（如颜色，形状，工具等）以监听单击事件等的UI组件。
模型-是定义您希望视图呈现和相应行为的业务逻辑的组件。
控制器-是更改模型的组件，因此，如果视图例如有一个名称要保存，则视图将其传递给控制器，然后控制器使用正确的操作来操作模型。
MVP-模型视图展示器
MVC的问题在于三个组件之间存在很大的耦合，如果要更改视图调用，则需要更新控制器和模型。从MVC图片中可以看出，三个组件之间的关系非常紧密，不能替换其中一个组件而没有其他组件。
因此，MVP通过分离模型和视图，通过Presenter保持它们之间的交互，提供了更清晰的解决方案。Presenter是视图和模型调用的中间人。因此，如果要保存收藏电影列表，则视图侦听用户(*)操作，然后调用Presenter函数更新模型，然后模型告诉Presenter是否成功，Presenter告诉视图显示正确的消息。
MVVM - Model View ViewModel
随着反应式编程范例的兴起，很明显我们可以通过观察变化并对其进行操作来在UI应用程序中提供更多的关注点分离。例如，当视图中有一个点击事件需要调用API以获取最新的电视节目时。此视图点击将在ViewModel中被观察到，ViewModel与Model交互以获取数据，最后ViewModel使用其他观察者将这些数据发布到视图上。
简而言之，View观察ViewModel以获取UI更新，而ViewModel观察View以使用Model调用正确的操作。观察者模式已经证明了它在解耦逻辑方面的价值，因此这里介绍了一种新的模式。
所以在讨论最流行的架构模式后，每个模式都试图将UI代码与业务代码解耦。但是先前的模式没有将更新UI与同时的不同状态绑定起来。
如果您遇到与加载出现错误消息同时显示有关的问题，您将理解我在说什么，因此为了保持UI状态，您必须做额外的努力查看您写错了什么导致这些问题。
MVI-Model View Intent
MVI基于一个叫做有限状态机的旧想法，任何系统或组件都有可预测的一组状态，是一个有限状态机。在MVI中，UI的任何更新都由新状态定义，你可以将其视为每次UI更改的截图。现在你可以调试、测试和重现状态问题了。
如何实现这一点，这就是MVI的实践。用户与UI的任何交互，在MVI中都由Intent定义，Intent是用户从这个操作中需要的内容，它可以是收藏电影、刷新屏幕，甚至可能是打开屏幕，在这种情况下，Intent是一个显示屏幕并提供所有所需数据的初始Intent。
哪个组件获取这些意图并据此采取行动，这是由您定义的...您可以使用Presenter或ViewModel，这并不重要，MVI更多是一种实践，而不是使用新的中间组件。
我将继续使用ViewModel，ViewModel将获取这些意图，决定调用哪个用例（模型行为）。
所有用例都通过ViewModel中的夏季函数，决定需要反映到View的状态，它还提供了先前的状态，因此您有先前和新状态来更新屏幕，从而减少渲染更新，并且View只获取更新自身所需的新提示。
最后，MVI是单向流，它始于View并以View结束。
MVI在状态管理方面与众不同，它是几种构建更稳定、可测试应用程序的思想的组合。
{{... View -> ViewModel/Presenter -> Model -> View -> ...}}
- Mohamed Ibrahim
10
这里有一个非常好的分析：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/View部分。 状态不会被修改，新状态是通过意图和一系列用例计算得出的。这个概念在这里解释得相当清楚：https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a。
这项技术旨在解决现代UI应用程序越来越复杂的问题，这些应用程序具有大量需要明确管理的客户端状态。 经验丰富的程序员都知道，最复杂的故障来自于以意想不到的方式修改的状态。 这种状态操作可能导致您的应用程序无法处理的“无效”状态，即崩溃的应用程序。 MVI通过使状态转换明确和仔细结构化来解决这个问题，从而系统永远不会出现无效状态，并且状态始终是可理解的。
- Rob Conklin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接