Maui: MVU 可能不是你想的那样

谢谢@aspnetde ，我希望你能加入我们，我们将在接下来的 18 个月左右努力实现这个想法。 鉴于您在 MVU 的历史，我希望您能做出很多贡献。

我认为现在说 .NET MAUI 是或不是 MVU 还为时过早，因为我们还没有真正构建它。 :)

是的，我们有一个原型。 是的，它的灵感来自彗星实验。 是的，我们知道有人担心我们迄今为止所展示的内容与每个人对 MVU 的定义都不匹配。

我希望我们可以合作！ 如果我们最终设计和运输的东西值得一个不同的标签，我同意我们应该给它一个。

您希望如何在 .NET MAUI 中看到 C# MVU？

如果有的话，您认为需要哪些新的语言功能？

我们可以/应该考虑集成 Fabulous 和/或在 C# 和 F# 之间通用的模式是什么，应该有什么不同？

您希望如何在 .NET MAUI 中看到 C# MVU？

你有没有听过有人说 C# MVC 或 C# MVVM？ _Model-View-Update_ 又名 _The Elm Architecture_ 是一种定义良好的架构模式，而不是依赖于语言的实现。

如果有的话，您认为需要哪些新的语言功能？

• 虽然联合类型有助于大规模简化消息的定义，但可以通过接口/抽象类和每个消息的子类来完成，尽管这需要编写更多样板代码。
• 为了处理消息，如果不需要，模式匹配很有帮助。 我认为 C# switch 表达式的当前状态已经足够好，因为消息的形状会很简单。
• 最后但并非最不重要的一点是，我看到的最重要的特性是默认情况下的不变性并启用了结构相等比较。 据我记得目前 C# 9（又名数据类）中记录的提议，那些将完全实现这一点。

所以 C# 9 虽然仍然比 F# 更吵，但从我目前的角度来看是好的。

我们可以/应该考虑集成 Fabulous 和/或在 C# 和 F# 之间通用的模式是什么，应该有什么不同？

如上所述，整个方法中不应该有任何特定于语言的内容，因为 MVU 本身就是您所说的架构风格或应用程序模型。

@TimLariviere最近提出了一些推进 Fabulous 的建议，其中还包括围绕更类似于 SwiftUI 的 DSL 的想法。 您可能也想在那里看看和/或参与。

顺便说一句：我去年对 XF + C# + MVVM 和 XF + F# + MVU 进行了 1:1 的比较，结果可以在这里找到——包括源代码。

我认为现在说 .NET MAUI 是或不是 MVU 还为时过早

这与 MAUI 最终是否会成为 MVU 无关。 这是关于公告博客中的示例，它已经在社区中引起了如此多的混乱。 基本上我不得不假设作者还没有真正研究过 MVU。 谈论“C# MVU”并没有让这变得更好。

我同意@aspnetde和@forki 的观点，这里的问题在于沟通。

我认为我们都没有争论放弃或更改受彗星启发的 C# DSL 用于 MAUI/XF，但即使我们采取到目前为止所做的工作，这仍然使用作为 MVVM 模式一部分的下划线绑定概念.

这是我在直接沟通和问题中一遍又一遍地问的问题，对于参与的每个人来说，阅读 MVVM 和 MVU 等不同模式可能是一个很好的想法。

话虽如此，甚至还有一种在 MVVM 之上实现 MVU 的方法，但问题仍然是它将解决什么问题。

你有没有听过有人说 C# MVC 或 C# MVVM？

是的，我知道说 C# 或 XAML 后跟 MVVM 或 MVU 之类的架构模式很奇怪。 在与我交谈过的更广泛的开发人员社区中，有必要明确表示您可以在项目中使用任意数量的组合。 其目的并不是说“C# MVVM”在架构上与“XAML MVVM”不同，而是说组合是可能的，因此作为一个整体的开发人员体验略有不同。

我认为这个线程可能会讨论 MVU 在 .NET MAUI 中的外观，但也许这里更有成效的讨论是我们如何讨论单个产品中的多个开发人员体验和架构模式？

这似乎是这里大多数评论的方向，想要讨论我们所说的和标记事物以及我们如何使用术语。 我非常喜欢您在这方面的意见，因为我进行了很多沟通，并希望确保我确实在增加清晰度并且不会产生混淆。

这是关于公告博客中的示例，它已经在社区中引起了如此多的混乱。

那是我对博客的贡献，我为它给你造成的混乱道歉。 通过添加指向 Elm 和@aspnetde博客的链接，我误MVU是什么”，而且我没有预料到代码片段会对那些拥有现有 MVU 经验和期望的人承担多少重量至于它在这里/应该是什么样子。

基本上我不得不假设作者还没有真正研究过 MVU。

我们就这个话题进行了广泛的对话和辩论。 请不要假设，我也会尽量不要假设。

问题仍然是它将解决什么问题。

@dersia要解决的一般问题是为开发人员提供选择。 如果您要问 MVVM 之上的 MVU 解决了什么问题，我不知道——这不是我们所要求的或我们正在尝试做的事情。

#28 和 #66 中提出的重构部分是将数据绑定和 MVVM 特定的东西从渲染器实现中分离出来，这样如果您选择 MVU，您将不会使用 MVVM 中使用的其他功能。

我没想到代码片段会承受多大的重量

但这就是肉，对吧？ 我很抱歉它与标签不符。

@davidortinau

这似乎是这里大多数评论的方向，想要讨论我们所说的和标记事物以及我们如何使用术语。 我非常喜欢您在这方面的意见，因为我进行了很多沟通，并希望确保我确实在增加清晰度并且不会产生混淆。

我不确定我身边还有什么要补充的。 我想我大声而清晰地表达了我的立场:-)。 如果您要实施 MVU，您将推开门。 如果可以通过查看公告帖子和 Comet 存储库中的片段来假设，请随意这样做 - 但_请_不要再称它为 MVU。

谢谢。

正如此线程中提到的那样 :-) - CC： @dsyme

我不明白为什么这被称为 MVU，而不是。 这可能是一个很好的范式，在这里工作得很好——为什么不想出一个适合范式并且不会混淆的合适术语呢？

@aspnetde你身边留下了什么？ 我想很多:)。
我读了你论文的一些部分。 我不得不说我喜欢它。 我还阅读了 Don Syme 关于 F# 的书。 我喜欢函数式编程。 根据我的经验，它简洁，但难以掌握（理解）。 可读性是开发生命周期中非常重要的一部分。 很多时间实际上都花在了阅读代码上。 递归是只写的。 你可以写一次，但几乎没有人能读懂它（类似于正则表达式）。
过去，我在公司的原型设计/研究期间尝试了 Redux 和 Angular。 它是半 Elmish 方法吗？ 这是一次宝贵的经历。 我了解到我必须注意不要改变状态，因此我不必记住整个堆栈，因为状态会突然改变。
我理解不变性的好处，但我看到了 Erik Meijer 的演讲，他突然撕开了一个泰迪熊的头，向我们展示了现实世界是可变的。

所以我想指出的是：我们的自然思维不是反对这些范式吗？ 你的经验是什么？

我在 XAML/C#/MVVM 方面有很多经验，所以我想知道为什么 Don Syme 认为 XAML 是不必要的。
根据我的经验，它有助于分离关注点（UI、演示、业务等逻辑）。 我不确定这些 DSL（C# 标记）和 MVU 是否有助于长期提高代码质量。 没有经验/不关心的开发人员将混合责任。 我还需要更多 MVU 模式的经验，才能正确理解它，但是您尝试了这两种范式，它对整个社区都非常有价值。
请尽可能多地分享。 谢谢@aspnetde！

非常感谢大家的理解

@davitortinau也许这里有一个误解，我完全可以选择，让每个人自己选择使用什么模式/范式。 我只是想说，我们应该正确命名事物。 正如软件开发中的每个人都知道命名事物是最难的事情之一，但是如果已经有定义明确的事物命名，我们不应该开始为它们没有的事物重用这些名称。

沟通不畅沟通
在这种情况下，我认为需要修复使用错误的措辞，为此我希望这个项目能够
a) 理解 MVU 是我们在这里谈论的错误名称
b) 找到合适的术语来描述我们在这里试图建立的内容
然后 c) 更新每个人并开始使用该新名称

我认为我们仍然处于我们仍然可以回去修复它的地步。 让我们做对吧，可能发生的最糟糕的事情是 XF/Maui 社区将 MVU 理解为不同于世界其他地方的东西。

话虽如此，我是 MVU 的忠实拥护者，我也喜欢 MVVM，而且我认为 Comet 中的流畅 MVVM 方法（我还没有更好的名字）以及到目前为止所呈现的内容很棒并且有助于很多开发人员，我会支持它，我只是认为我们应该修复命名。

编辑：错过通讯退出比赛。

我了解不变性的好处，但我看到了 Erik Meijer 的演讲，他突然撕开了一个泰迪熊的头，向我们展示了现实世界是可变的。

@tomasfabian这是错误的。

您必须开始将世界视为一系列事件，实际上就是这样（不，我不想在这里开始事件溯源讨论）。
发生在泰迪熊身上的只是在其状态中添加了一个新事件，在这种情况下，该事件是“被撕毁的”。 而且您无法意识到一旦事件发生就无法恢复，因为您不能只是撤消或删除发生的事情。 要将头部重新放在泰迪熊身上，您需要一个名为“将头部缝合到身体上”的新事件。 😉

讨论 FP 和 MVU 的好处与否是恕我直言，这里是题外话。 这个问题，我想，只是关于误解和准确命名的可能性。

@isaacabraham也许您是对的，对此我深表歉意。 这是我的错。 我知道命名很重要，但另一方面，问题的标题是“MVU 可能不是你想象的那样”。 因此，希望它是一个比命名事物更广泛的话题。
谢谢你，托马斯

@tomasfabian我非常乐意与您讨论 MVU、FP 或其他任何东西的优缺点，无论是真实的还是虚构的😊只是不要认为这是适合它的论坛。

@davidortinau
至于哪些语言特性和架构更改会有所帮助，希望我能提供一些建议：

* new关键字和其他语法噪音。
与 Dart 或 Kotlin 不同，C# 可能永远被必需的new关键字所束缚，因为使其可选是一项重大更改，并且即使作为每个文件的选择加入指令也是一个不受欢迎的提议。 因此，取而代之的是，可能是一个官方（和维护的）静态类（或每个 MAUI 视图命名空间的静态类），其中包含仅包装构造函数并初始化任何仅初始化属性（如果有）的静态方法，至少对于核心集MAUI 视图对象。 然后我们可以在视图代码 .cs 文件的顶部放置一个using static指令，然后在没有new语法噪音的情况下调用方法。 这会稍微减少 C# 视图函数的混乱和噪音。 当然，这些静态方法构造函数包装器可以由社区自动生成（我已经为 Xamarin.Forms 与 CSharpForMarkup 一起使用做过类似的事情），但最好有一组现成的它们由维护MAUI 项目。

此外，任何有助于减少大型表达式树中的语法混乱或噪音的 C# 语言建议（在 MVU/Comet/CSharpForMarkup 视图函数中很常见）都会有很大帮助。 C#9 在这方面已经走了很长的路来改进 MVU 的 M 和 U 部分，但 V 部分仍然是语法方面的痛点。

* 扩展属性 *
我知道“extension-everything”提案目前处于搁置状态，但对于 MVVM-with-C#-markup（例如 CSharpForMarkup 和 Xamarin.Forms）可能有帮助的一件事是扩展属性。 使用 CSharpForMarkup，每个助手都必须使用扩展方法来实现，但在某些情况下，扩展属性（可在对象初始化器中使用）看起来会好很多：

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

这仅适用于可变视图对象树，例如在 MVVM 中使用 C# 进行标记。 对于 MVU 或其他功能 UI 架构，这不适用，因为视图对象是不可变的。 在这些情况下，流畅的扩展方法仍然更合适。

* 对状态管理不那么固执己见（或低级，如果你愿意的话）*
我认为在 Xamarin.Forms 上实现 MVU 的最大障碍之一是缺少两个基本组件：视图函数可以返回的轻量级对象图，框架可以将其“渲染”为实际组件（使用它们的特定于平台的表示等...）。 第二部分是一个差异引擎，它通过查找视图函数的一个返回值与另一个返回值之间的差异来有效地更新重量级平台特定视图，包括一种通过执行部分差异等来有效地执行差异的方法......

听起来 MAUI 现在提供了这两个必不可少的部分，太棒了！ 然而，至少从表面上看，它似乎与一种固执己见的状态管理方式密切相关，MVU 社区中的一些人会说这种方式更接近 MVVM，而不是 MVU 或类似的“功能性”UI 架构。 我认为我的偏好是保留我上面提到的两个基本部分（轻量级视图对象图和高效的差异引擎），并将其与较低级别的组件系统结合起来，根据开发人员的说法，MVU 或 Comet 可以有效地在其上分层选择。 也许这已经是目标，而我没有看到它？ 如果是这样，我希望看到更多关于这个问题的讨论，至少有一些基本的例子。

@aspnetde你为什么删除你的帖子？

@tomasfabian

根据我的经验，它 [MVVM] 有助于分离关注点（UI、表示、业务等逻辑）

是的，它确实。 我在使用 MvvmCross 构建的大型 Xamarin.iOS 和 Xamarin.Android 应用程序方面取得了一些很好的经验。 尽管今天我更喜欢库而不是框架，但我认为所有这些项目（一些具有六位数 LOC）在技术上以及从业务角度来看都是成功的。

我认为 MVVM 在扩展应用程序方面做得特别好。 尤其是在移动领域，我们被迫交付单体应用程序，它帮助我们在应用程序超过一定大小后将它们重构为独立的模块。

我们的自然思维不是反对这些范式（[MVU]）吗？ 你的经验是什么？

我不这么认为。 以您使用 Redux 的存储体验为例，想象您的整个应用程序将从它的优势中受益。 虽然乍一看它似乎更复杂，但根据我的经验，它更易于理解和使用。 正如@forki经常指出的那样，这几乎很无聊，因为单向数据流清楚地表明了一直发生的事情。

我不确定这些 DSL（C# 标记）和 MVU 是否有助于长期提高代码质量。

虽然 MVU 和 MVVM 都有不同的优点，但也有不同的缺点。

尽管考虑到我们的 MVVM 项目是成功的，但我和我的团队在调试它们时失去了一些头发。 特别是在一个项目中，由于新团队成员缺乏经验和误解，我们开始遭受复杂性的困扰——正如您已经指出的那样。 我认为在严格应用时，MVU 不太可能发生这种情况，因为它定义了事物如何工作的边界如此狭窄，以至于打破它并以错误的方式构建事物几乎比相反的方式更难。

对于 MVU，我看到了两个主要问题。 第一：缩放。 许多人提倡单一计划。 我对此持怀疑态度（并认为多个程序/模块会是更好的方法）。 第二：现在，像 Fabulous 这样的东西位于 Xamarin.Forms 之上。 因此，它是在 iOS/Android 之上的抽象层之上的抽象层之上的抽象层。 这是一个巨大的复杂性。 因此，您不仅要处理没人关心的未解决的错误，而且当另一个抽象层 (Xamarin.Forms) 发生更改时，更新一个抽象层 (Fabulous) 也是一项或多或少乏味和不愉快的工作。

这就是我认为 MAUI 有很大机会的地方。 老实说，我很想看到 Fabulous 的维护者在这里与 Microsoft 联手。 我真的希望微软不会像组织的其他部分过去所做的那样毁掉它。

托马斯

前几天我在阅读官方公告时，我很惊讶那里显示为 MVU：

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

就我而言，这不是 MVU 。 我已经写了下来，为什么我是这样认为的一些想法在这里。

据我了解，Don Syme 在 2018 年花了几个月的时间在 Xamarin.Forms 之上实施 MVU 并构建后来成为Fabulous 的东西，他有点外交，但底线是一样的。

那么，我的意思是什么？

• 我希望你实现真正的架构模式，无论是在 C# 还是 F# 中。 接触 Fabulous 背后的人可能是这里的一个开始。
• 如果您对此不感兴趣，但对在目前可用的Comet 库之上构建有清晰的愿景，那么请考虑为该“应用程序模型”使用更合适的名称。 发明一些新东西。 将其命名为 MSMVU。 任何。 但是不要卖苹果换橙子。

干杯!

他们为什么将其命名为 MSMVU？ Comet 已成为 MVU，并且将一直如此。 毛伊岛是一个MVU。

我认为现在说 .NET MAUI 是或不是 MVU 还为时过早

这与 MAUI 最终是否会成为 MVU 无关。 这是关于公告博客中的示例，它已经在社区中引起了如此多的混乱。 基本上我不得不假设作者还没有真正研究过 MVU。 谈论“C# MVU”并没有让这变得更好。

它不会引起任何混乱。 只是有些人无法处理看到 C# 做 MVU 的情况。

就其价值而言，SwiftUI（Comet 的大部分灵感都来自于它）倾向于将其模式称为 MVVM，即使没有明确的指导方针。
不过，我还没有找到任何提及 MVU 的内容。

@TimLariviere https://github.com/Clancey/Comet#key -concepts
基本上 Comet 将其称为 MVU 并且已经忽略了我们在旧的 MVU 定义中的消息循环点

就其价值而言，SwiftUI（Comet 的大部分灵感都来自于它）倾向于将其模式称为 MVVM，即使没有明确的指导方针。

甚至没有错，在这里查看本文开头的示例： https :

不过，我还没有找到任何提及 MVU 的内容。

同一篇文章也简要讨论了它（作为 SwiftUI + Redux = TEA 的组合）。 虽然它正在奇怪地转向“清洁建筑”😄

既然提到了这里，我就简单说几句。

• 我认为 MAUI 很棒，我认为学习 MVU 作为一种架构对于人们理解 MAUI 很有用。

• 单词很容易挂断，在这个阶段我们可能都应该休息一下，尽量不要担心，因为有足够的时间来调整使用的单词，我认为关于准确术语的信息已经听到。 就我个人而言，我认为 Elm 已经确定，“MVU”的朴素、无条件使用意味着显式消息、显式更新、功能模型、功能视图重新计算和差异更新。 但是MVU有许多

• 我注意到人们在这个领域往往有非常强烈的信念和观点，并且可以非常个人化地对待事情。 我知道那是什么样的，就像编程语言设计一样，我认为该领域的所有观点都有利有弊。 我鼓励每个人尝试、使用、学习、分享和共同努力，以使最好的技术成为可能。

@dsyme
我认为 Comet/MAUI 架构的正确术语是单向数据流（或 UDF）的变体，但不是 MVU，因为 MVU 本身就是 UDF 的一个非常具体的变体。 MAUI/Comet 确实符合 UDF 框架的要求（SwiftUI 也是如此），但它不符合 MVU 框架的要求。 UDF 有多种变体，包括 MVU、Flux、Redux、React 等……但是当它根本不是 MVU 时，将 Comet MVU 称为是一种误解。

与 MVU 不同，Model 是可变的，并且由 View 函数中的代码改变。 然后观察突变，视图通过重新渲染对这些突变做出反应。 它仍然是单向的，因为视图没有发生变异，但是没有更新功能，没有消息，也没有消息调度——因此，不是 MVU。 它更接近于 MVVM 的单向变体。

@JeroMiya谢谢，您有该术语的参考吗？

@dsyme我没有具体的参考，但我第一次听到 React 早期使用的术语，特别是指 React 本身和一些出现的早期模式，如 Redux 和 Flux。 我记得有一篇文章描述了许多 UDF 变体（主要在 React 领域），但现在找不到了。

话虽这么说，它不是一个正式的架构 - 更像是视图的基本概念是模型的函数，而不是视图是响应事件而发生变化的有状态对象树。 UDF 概念不一定指定模型如何更新或者它是可变的还是不可变的。 MVU 不仅将 UDF 概念扩展到视图本身，还扩展到更新模型的过程。 因此，在 MVU 中，模型也是不可变的，UI 状态更改表示为生成新模型的命令，从而触发新视图。

这当然不是一个新概念——甚至在 React 之前，大多数服务器端 Web 框架（如 Asp.Net MVC、Rails，甚至 PHP）在技术上都算作单向的。 在 React 出现之前，主流 SPA 框架和客户端 UI 框架并不常见。

@dsyme我没有具体的参考，但我第一次听到 React 早期使用的术语，特别是指 React 本身和一些出现的早期模式，如 Redux 和 Flux。 我记得有一篇文章描述了许多 UDF 变体（主要在 React 领域），但现在找不到了。

话虽这么说，它不是一个正式的架构 - 更像是视图的基本概念是模型的函数，而不是视图是响应事件而发生变化的有状态对象树。 UDF 概念不一定指定模型如何更新或者它是可变的还是不可变的。 MVU 不仅将 UDF 概念扩展到视图本身，还扩展到更新模型的过程。 因此，在 MVU 中，模型也是不可变的，UI 状态更改表示为生成新模型的命令，从而触发新视图。

这当然不是一个新概念——甚至在 React 之前，大多数服务器端 Web 框架（如 Asp.Net MVC、Rails，甚至 PHP）在技术上都算作单向的。 在 React 出现之前，主流 SPA 框架和客户端 UI 框架并不常见。

@JeroMiya 对此表示感谢，这正是我对
我什至会说，MS Excel 是最古老且仍然主要使用的应用程序之一，它以最佳形式使用和示例 MVU。

@dsyme阅读您的评论我感觉您将 MAUI 称为所讨论架构的术语（带有 MVVM 的 CSharpForMarkup）。
请为我澄清，这不是您所理解的 MAUI 或如果它是。
据我了解，MAUI 只是未来某个时候取代 XF 的下一个 MS 应用程序框架。

我真的很喜欢这个问题的方式和它的评论。 感谢大家的参与。 也许我们可以一起获得所有不同的架构，作为 MAUI 的可能风格，并正确命名。

@dersia谢谢！ 只是我自己对 CSharpForMarkup 的经验的一点说明：它比 MVVM 低一点——更多的是一组扩展方法和实用程序，可以使 C# 标记更加精简和美观。 你当然可以用它实现一个 MVVM 模式，因为它有帮助 ViewModel 绑定更容易，但我最终做的是在 Redux 而不是 ViewModels 中实现我的所有视图逻辑。 只需要添加一些扩展方法来将视图属性绑定到状态选择器，它们只是Func<StateType, ChildStateType>我传递给 Redux 状态存储的Select和DistinctUntilChanged运算符，即一个Observable<StateType> 。 不是完全单向的数据流，但我没有像现在 Fabulous 那样做 UI 对象树差异和查看功能的成熟方法。

前段时间，REST 警察试图把它塞进我们的喉咙里，我们所做的不应该被称为 REST。 今天每个人都称它为 REST，我们都还活着，而且很好。 😉

@bitbonk REST 社区放弃了这个术语，因为随着越来越多的东西被混入其中，它变得越来越没用。 他们现在使用“超媒体”来指代代表性状态转移。 REST，今天，现在实际上只意味着“不是 SOAP”或“JSON over HTTP”，它们都没有成功地传达其核心思想。 这里的评论者希望避免 MVU 的同样命运。

@davitortinau @tomasfabian ，我还没有看到 MAUI 上的这里为 WinForms 做了类似的事情。 我想应该不会太难。

@JeroMiya谢谢，您有该术语的参考吗？

@dsyme ，我认为它起源于 React Flux，但他们指出了游戏架构，即 Doom 3。我想我记得在第一次出现时与@TIHan讨论过这个问题。

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirectional-data-flow

这是我对 C# 示例的尝试。 我没有可用的 MAUI 来尝试这个作为一个真实的例子。 没有预览，是吗？ 无论如何，这是对这个想法的粗略翻译。

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

我曾经短暂地尝试过类似的东西，除了视图部分。 随着 Records 进入 C# 9，这将更加合理。

我对 MVU 比较陌生，与你们中的许多人相比，我可能没有使用它的经验。 但是 MVU 的概念确实引起了我的兴趣，我很享受。 我很高兴看到 C# 开发人员获得了一个框架来帮助以 MVU 模式进行开发。

我完全同意 MAUI MVU 不是典型的 MVU，它受到 SwiftUI 的巨大影响。 它的主要作者 Clancey himeslef 在他的几乎所有课程中都非常清楚地表明了这一点。 我们都知道 Redux 深受 MVU 的影响，SwiftUI、Flutter 和许多其他框架也是如此。 它们都不是纯 MVU。

但我敢肯定，我们都同意所有这些框架最接近的架构模式是 MVU。 这就是人们引用它的原因。 请记住，我们正在讨论一个框架的博客标题，该框架将在一年半后发布。

如果你说人们对这个博客标题感到愤怒。 我不认为我们真的应该担心他们。 社区仍然需要继续前进。 让我们花精力让这个框架变得更好。 不要太在意小细节。

但我敢肯定，我们都同意所有这些框架最接近的架构模式是 MVU。 这就是人们引用它的原因。

狗、马、猫和黑猩猩都非常接近。 从现在开始，我将它们统称为猫。

:) 那么你不必。 但是让我告诉你一些事情：猫，老虎，豹子等被称为猫。 我很高兴你提出来。 因为这正是这里的情况。

@aspnetde ：Thomas，说了这么多。 我需要说你原来的 MVU 博客是最好的文章之一，它非常清楚和准确地解释了这个概念。 我从中学到了不少东西。 谢谢

@libin85这正是问题所在。 你开始列举实际上属于一类的事物，而忽略了那些不属于这一类的事物。 通过将 MAUI 样本放入 MVU 类别，您基本上可以将黑猩猩放入猫类别。

它们与 MVU 实现有相似之处，例如不可变视图。 但是有明显的区别，比如没有消息循环，也没有明确的更新功能。 模型直接在视图中进行变异。 这是人们在提出 MVU 时明确不想要的。 在某些语言中，甚至不可能做到这一点——这就是 MVU 出现的原因。 以及为什么它变得流行。 现在，如果我们从 MVU 的定义中删除这些属性，我们应该小心。

@forki ：我不反对你所说的。 事实上，正是您在上一条评论中提出的那些观点，我们需要作为一个社区来讨论，而不是在博客文章中的标题。 这就是我的观点。 这是一件值得讨论的积极事情，框架将从中受益。

我同意这个名字是一个小细节，不应该分散更重要的方面。 然而，我提出这个问题的原因是，我个人并不认为 MAUI 是一种社区努力，常识最终会导致普遍认可的解决方案。 这是一个 Microsoft 产品，最终决定是在闭门造车的情况下做出的。 作为客户，我有能力在这里提出我的担忧。

但我敢肯定，我们都同意所有这些框架最接近的架构模式是 MVU。

@libin85我不同意这是最接近的架构模式。 MVU 是一组约束，这些约束看起来更像是 MVP，或 Model View Presenter。 MVVM 与此类似，但其方向不同，因为它的 Presenter 是具有数据绑定的 ViewModel。 MVP 本身是 MVC 的一种受限形式。 我觉得说这些都是 MVC 甚至 MVP 的后代是相当有把握的，但是说 MVU 适用于 SwiftUI、Flux 等就是让 MVU 成为一个没有意义的名词。

我同意这个名字是一个小细节，不应该分散更重要的方面。

不，名字很重要。 它们很难确立和保持其意义。 另请参阅我在上面讨论过的 REST。 REST 被滥用得如此之多，以至于除了作为营销术语外，它不再有意义。 我不希望这种情况发生在 MVU 上，尤其是当 MAUI 的“MVU”提供的内容存在现有条款时。

对于它的价值，我认为 MAUI "MVU" 是 MVVM 选项的一个不错的替代品。 就像使用 REST 一样，您不必做定义性的事情来使某些东西变得有用和好。 请不要用明显偏离明确定义和既定模式的替代方案来混淆名称。 毕竟，MVU _也_是 MVVM 和 Comet 选项的一个不错的选择。

对于它的价值，我认为 MAUI "MVU" 是 MVVM 选项的一个不错的替代品。 就像 REST 一样，您不必做定义性的事情来使某些东西有用和好，只是请不要用明显偏离其定义的替代品来混淆名称。

完全确认。

他们为什么将其命名为 MSMVU？ Comet 已成为 MVU，并且将一直如此。 毛伊岛是一个MVU。

@saint4eva他们被“营销”为，但根据定义不是，MVU。

我同意这个名字是一个小细节，不应该分散更重要的方面。

不，名字很重要。 它们很难确立和保持其意义。 另请参阅我在上面讨论过的 REST。 REST 被滥用得如此之多，以至于除了作为营销术语外，它不再有意义。 我不希望这种情况发生在 MVU 上，尤其是当 MAUI 的“MVU”提供的内容存在现有条款时。

对于它的价值，我认为 MAUI "MVU" 是 MVVM 选项的一个不错的替代品。 就像使用 REST 一样，您不必做定义性的事情来使某些东西变得有用和好。 请不要用明显偏离明确定义和既定模式的替代方案来混淆名称。 毕竟，MVU _也_是 MVVM 和 Comet 选项的一个不错的选择。

我同意你所说的大部分内容，但我认为“Maui MVU”仍然很糟糕和令人困惑。 我可能会选择“Maui MVP”或 MVC。 两者都有效，并且比 MVU 更接近博客文章中介绍的内容。

编辑添加：
我什至不确定提议的版本在哪里。 我的意思是 MVVM 中的逻辑存在于 ViewModel 中，MVU 存在于更新函数中，MVP 存在于 Presenter 中，而 MVC 存在于 Controller 中。

是否会有一个万物皆可居住的视图？ 还是它们都存在于某个由域模型命名的类中，为视图、逻辑和模型提供服务？ 模型应该是单独的类（类型）还是记录？

我认为这对我来说是这里的主要痛点，我不知道它是如何“呈现”的，因此我看不到有更新、模型和视图功能。

开箱即用，在我看来 MAUI 比目前讨论的模式低一点——实际上只是模型（或状态）和其他模式的视图部分。 您也许可以在此基础上实现这些其他模式（尽管状态管理有点固执己见）。

例如，如果State<T>的T是一个类似于 ViewModel 的类，并且您添加了一组单独的数据模型类，那么您最终会得到类似 MVVM 的东西单向视图。

另一方面，如果你添加一个类似 Redux 的状态管理系统，并将 Redux 状态模型作为你的T插入State<T> ，那么你最终会得到非常接近 MVU 的东西，虽然不像 Elm/Fabulous 这样的传统 MVU 那样完全集成。 也许您可以将 MAUI 视图隐藏在 MVU 框架后面，就像 Fabulous 对 Xamarin.Forms 所做的那样？

我不确定您将如何通过 MAUI 实现 MVC 或 MVP 模式。 作为粗略的第一步，我想也许你创建了一个单独的类，将“动作”暴露给视图函数。 例如，假设您有一个 MAUI 确认对话框，并且您的“控制器”类有一个“ClickOK”方法和一个“ClickCancel”方法。 MAUI 视图会将点击事件从视图转发到控制器，控制器将生成新模型或改变现有模型。

@JeroMiya我同意，绝对使用 Redux 模式可以使其更接近 MVU 并使架构不那么自以为是。 我是 React-Redux、React-Hooks、ReactiveX 以及最近使用 Blazor 应用程序的快乐用户 :heart: Fluxor :heart: 。 @mrpmorris可能会贡献这个对话。

这是我对 C# 示例的尝试。 我没有可用的 MAUI 来尝试这个作为一个真实的例子。 没有预览，是吗？ 无论如何，这是对这个想法的粗略翻译。

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

与 Microsoft 示例相比，这会产生更多的更新性能成本吗？ 在这个模型中，如果我理解的话，将实例化一个包含所有 UI 元素的新视图，而不是在 MS 示例中，将现有的视图元素留在原处并仅更新标签的值（产生任何重新-这可能具有的规模成本）。

这种差异似乎是推动围绕命名进行讨论的核心差异之一，因此我很好奇在传统定义的 MVU 架构中是否还有其他技术可以有效更新 UI，如果是，它们是否在渲染引擎？

@markmccaigue在性能方面：

你好！！

我现在要关闭这个问题..我想对此进行讨论，但 github 不想让它工作:-/

如果有人想继续这个对话，请创建一个讨论项目，然后引用这个问题