MVC - Model-View-Controller

MVC是一种经典的架构模式，MVC通过分离Model、View和Contraller的方式来组织代码结构。

• Model：负责数据的管理及对相应数据的操作。例如，在一个博客应用中，Model可能包括文章、评论等数据模型，以及相关的数据库操作。
• View：负责用户界面的展示。它通常是一个HTML页面或者一个移动应用的界面元素，如按钮、文本框等。
• Controller：作为中间件，处理用户请求，调用Model进行数据处理，并更新View以反映最新的状态。其是业务的主要承载者，几乎所有的业务逻辑都在Controller中进行编写，而Controller一般都在View层上写，密不可分

• 在MVC中，View需要主动从Model中获取数据，并由Controller负责将数据传递给View进行展示。这使得开发者需要手动编写代码来同步更新数据和UI
• 缺点：对于庞大的业务而言，一个View页面能达上千行代码，太臃肿

示例

假设我们正在开发一个简单的博客应用：

1. Model：定义了Post类，包含文章的标题、内容等属性，以及从数据库读取文章的方法。
2. View：HTML页面，展示文章列表和详情。
3. Controller：处理用户请求，例如当用户点击“查看文章”按钮时，Controller会调用Model的getPostById方法获取文章数据，并将数据传递给View进行展示。

MVP - Model-View-Presenter

详细介绍

MVP是对MVC的一种改进，它进一步分离了View和Model，引入了Presenter作为两者之间的桥梁。

• Model：与MVC中的定义相同，负责数据管理和对相应数据的的操作。

• View：只负责展示数据，不包含任何业务逻辑。通常是一个接口，定义了View需要提供的方法。

• Presenter：处理业务逻辑，从Model获取数据，并准备数据给View。Presenter完全控制了View的更新。

• 

• MVP中，View层接收到事件后调用到业务层处理，业务层调用数据层处理数据，数据层处理数据后回调给业务层，业务层再回调给视图层更新页面。（数据层已不再持有视图层，他们之间通过业务层（Presenter）交互，具体使用接口实现，使数据层和视图层解耦.
  当业务复杂的时候，凌乱的Presenter，到处飞，一个View有十几种状态，但好在，它解耦啊，文件层级清晰。

示例

继续以博客应用为例：

1. Model：定义了Post类，包含文章的标题、内容等属性，以及从数据库读取文章的方法。
2. View：定义了一个接口，例如IPostView，包含显示文章列表和详情的方法。
3. Presenter：实现了业务逻辑，例如当用户点击“查看文章”按钮时，Presenter会调用Model的getPostById方法获取文章数据，并通过View接口的方法更新UI。

MVP模式与MVC唯一不同的在于Presenter和Contraller

• 在MVC模式中我们使用观察者模式，来实现Model层数据发生变化时通知View层的更新，这样View层和Model层耦合在一起，当项目逻辑变得复杂的时候，可能会造成代码的混乱，可能会对代码的复用性造成一些问题。
• MVP模式通过使用Presenter来实现对View层和Model层的解耦，MVC中的Contraller只知道Model的接口，因此它没有办法控制View层的更新，MVP模式中，View层的接口暴露给了Presenter，因此可以在Presenter中将Model的变化和View的变化绑定在一起，以此来实现View和Model的同步更新，实现了对View和Model的解耦

MVI - Model-View-Intent

MVI 是一种基于响应式编程的架构模式，它强调单向数据流和状态管理。MVI 通过意图（Intent）来驱动状态（State）的变化，这些变化最终会被视图（View）所感知并呈现出来。

MVI 的组成部分

1. Model

• 职责：负责存储应用程序的状态数据。
• 特点：通常是不可变的，每次状态更新都会创建一个新的状态对象。
• 示例：在博客应用中，Model 可能是一个包含评论列表的对象。

2. View

• 职责：负责显示界面，并将用户的操作转化为意图（Intent）。
• 特点：通常是一个简单的界面组件，不包含业务逻辑。
• 示例：在博客应用中，View 可能是一个显示评论列表的页面，并且有一个按钮用于提交新评论。

3. Intent

• 职责：表示用户的动作或外部事件。
• 特点：Intent 是应用程序的输入信号，用来触发状态的变化。
• 示例：在博客应用中，点击提交评论按钮就是一个 Intent。

4. State

• 职责：表示应用程序的当前状态。
• 特点：State 是应用程序的输出信号，用来更新 View。

示例

假设我们正在开发一个计数器应用：

1. Model：定义了一个CounterState类，包含当前的计数值。
2. View：展示当前的计数值，并提供一个按钮让用户增加计数。
3. Intent：用户点击“增加”按钮时，产生一个IncrementIntent。
4. Reducer：处理Intent，更新状态。例如，当收到IncrementIntent时，将计数值加1。
5. ViewState：新的状态被传递给View，更新UI。

注意：

• 状态管理：状态应该通过不可变对象来管理，这样可以确保每次状态变更都是一个新的对象。
• 意图处理：意图处理应该通过纯函数来完成，这样可以保证意图处理的确定性和可预测性。
• 视图更新：视图应该只负责显示数据，不应该包含任何业务逻辑。

MVVM - Model-View-ViewModel

MVVM通过数据绑定技术，进一步分离了View和ViewModel，使得UI的更新更加自动化。

• View：是用户界面的可视化部分，负责展示数据并与用户进行交互。View通常由XML、HTML、XAML等描述，这取决于具体的开发平台。
• Model：表示应用程序的数据模型或业务逻辑，负责处理数据的存取、处理和操作。它通常包含数据结构、数据库操作、网络请求等。Model并不直接与UI层交互，它只暴露一些接口供ViewModel层调用，使得ViewModel可以获取所需的数据。
• ViewModel：层类似媒婆，起到了牵线搭桥的作用，负责将数据从Model中取出并转换成View可用的形式。ViewModel不直接操作View，而是通过数据绑定机制将数据与View进行绑定，使得数据的变化可以自动反映在View上，实现了数据的双向绑定。

示例

假设我们正在开发一个天气应用：

1. Model：定义了Weather类，包含天气数据，以及从API获取天气信息的方法。
2. View：展示天气信息，例如温度、湿度等。使用数据绑定技术，当ViewModel中的数据变化时，View会自动更新。
3. ViewModel：包含一个可观察的属性weatherData，以及一个方法fetchWeather。当用户点击“获取天气”按钮时，ViewModel调用fetchWeather方法从API获取数据，并更新weatherData属性。

MVVM - Model-View-ViewModel（HarmonyOS）

• Model层：存储数据和相关逻辑的模型。它表示组件或其他相关业务逻辑之间传输的数据。Model是对原始数据的进一步处理。

• View层：在ArkUI中通常是@Component装饰组件渲染的UI。

• ViewModel层：在ArkUI中，ViewModel是存储在自定义组件的状态变量、LocalStorage和AppStorage中的数据。

• 自定义组件通过执行其build()方法或者@Builder装饰的方法来渲染UI，即ViewModel可以渲染View。View可以通过相应event handler来改变ViewModel，即事件驱动ViewModel的改变，另外ViewModel提供了@Watch回调方法用于监听状态数据的改变。在ViewModel被改变时，需要同步回Model层，这样才能保证ViewModel和Model的一致性，即应用自身数据的一致性。ViewModel结构设计应始终为了适配自定义组件的构建和更新，这也是将Model和ViewModel分开的原因。目前很多关于UI构造和更新的问题，都是由于ViewModel的设计并没有很好的支持自定义组件的渲染，或者试图去让自定义组件强行适配Model层，而中间没有用ViewModel来进行分离。例如，一个应用程序直接将SQL数据库中的数据读入内存，这种数据模型不能很好的直接适配自定义组件的渲染，所以在应用程序开发中需要适配ViewModel层。

比较

1. MVC vs MVP：

   • MVC：Controller直接操作View和Model，适用于简单的应用。
   • MVP：Presenter完全控制View的更新，适用于复杂的UI逻辑。

2. MVI vs MVVM：

   • MVI：强调单向数据流，适合需要严格控制状态变化的应用。
   • MVVM：通过数据绑定简化UI层的开发，适合需要快速响应用户输入的场景。

3. 通用特点：

   • 数据分离：所有模式都强调将数据逻辑和展示逻辑分离，提高代码的可维护性和可测试性。
   • 职责明确：每个组件都有明确的职责，避免了单一组件承担过多责任。

选择建议

• 简单应用：可以选择MVC，因为它结构简单，易于理解和实现。
• 复杂UI：可以选择MVP，因为Presenter可以更好地处理复杂的UI逻辑。
• 状态管理：可以选择MVI，因为它强调单向数据流，适合需要严格控制状态变化的应用。
• 快速开发：可以选择MVVM，因为数据绑定可以大大提高开发效率。