Flutter 有一整页专门用来吸引 Xamarin.Forms 的人。 你是说我们应该忽视竞争。 真的吗？

Blazor 绑定很漂亮！ 我刚刚开始使用它们，它们提供了 Flutter 的简单性。

@davidortinau正如我在另一个线程中所说的那样。 MAUI 的博客文章引起了巨大的混乱。 人们现在似乎认为 MVU = view as code/DSL。
但这完全独立于 MVU 是什么。 XAML 完全可以实现 MVU。 它与您如何编写视图无关。
这只是关于创建一个不可变的模型 + 更新函数，它接受一个模型和 msg 并构建一个新模型，以及一个不直接改变模型但将新命令（消息）发送到更新循环的视图函数。

我认为 MAUI 应该只坚持一种设计 UI 的方式，那就是： XAML

Blazor Syntex还可以，但

它适用于 C# 和 .NET 开发人员。

@sim756

我认为 MAUI 应该只坚持一种设计 UI 的方式，那就是：XAML

它从来都不是一种方式。 Xamarin.Forms 从一开始就支持基于代码的 UI。 让这更平易近人是有道理的。 顺便说一句：MVU 可以很容易地与 XAML（ Xamarin.Forms ， WPF ）一起使用。

@Happypig375

Flutter 有一整页专门用来吸引 Xamarin.Forms 的人。 你是说我们应该忽视竞争。 真的吗？

好吧，我们最好有“ Xamarin for Flutter devs ”页面！

@rohanbojja

Blazor 绑定很漂亮！ 我刚刚开始使用它们，它们提供了 Flutter 的简单性。

一切都只是这个没关系，和_this_就是为什么我不喜欢扑：

图片 0

@forki

@davidortinau正如我在另一个线程中所说的那样。 MAUI 的博客文章引起了巨大的混乱。 人们现在似乎认为 MVU = view as code/DSL。
但这完全独立于 MVU 是什么。 XAML 完全可以实现 MVU。 它与您如何编写视图无关。
这只是关于创建一个不可变的模型 + 更新函数，它接受一个模型和 msg 并构建一个新模型，以及一个不直接改变模型但将新命令（消息）发送到更新循环的视图函数。

我真的很困惑！！ 谢谢你，你刚刚说清楚了，帖子是灾难性的混乱：

图 1

@saint4eva

我认为 MAUI 应该只坚持一种设计 UI 的方式，那就是： XAML
Blazor Syntex还可以，但

它适用于 C# 和 .NET 开发人员。

“它是为 C# 和 .NET 开发人员设计的。 ”，确切地说，它不应该受到 Flutter 的影响（恐怕是..）。

@aspnetde

@sim756

我认为 MAUI 应该只坚持一种设计 UI 的方式，那就是：XAML

它从来都不是一种方式。 Xamarin.Forms 从一开始就支持基于代码的 UI。 让这更平易近人是有道理的。 顺便说一句：MVU 可以很容易地与 XAML（ Xamarin.Forms ， WPF ）一起使用。

我知道。 有时我们确实会写new Button() { .... } ，但是这篇文章（图 1 ）让我和许多其他人感到困惑，我相信。

@Happypig375

Flutter 有一整页专门用来吸引 Xamarin.Forms 的人。 你是说我们应该忽视竞争。 真的吗？

好吧，我们最好有“ Xamarin for Flutter devs ”页面！

哈哈。 想象一个专用于“WPF 开发人员的 Windows 窗体”的页面。

XAML 只是对象模型之上的一个“工具”……您可以使用 xaml、c#。 您可以使用 MVVM（使用或不使用 XAML）或使用 MVU（公平地提供的示例不是“真正的”MVU，但这是另一个主题）来构建您的应用程序。

如果您不喜欢编码的 ui 或 MVU 方法，请忽略它:) 没有必要将其推回。

我不认为这只是为了吸引 Flutter 开发者。 MVU 模式正在兴起，非常适合移动开发。

编码的 UI 也在增加……react、flutter、swiftUI、ecc……它们越来越受欢迎，而且不仅是炒作……如果做得好，编码的 UI 有很大的好处

@GiampaoloGabba
我想我应该说清楚，与 Coded-UI 相比，我更不反对 MVU。 我对那篇文章感到困惑，我担心 Coded-UI 将成为开发 UI 的默认方式（....我害怕丢失 XAML）。

好吧，我们有.designer.cs ，但我们不必在那里编辑代码，即使我猜许多 Windows 窗体开发人员甚至从未看到.designer.cs文件的内容。 但在这里，我们有 _capable_ GUI 编辑器，我们不必担心 _.designer.cs_ 文件中的编码 UI 代码。

我最好编辑一下这个问题的标题。

我想说的：

我们将在Flutter/Swift/Coded-UI和WPF/XAML之间选择什么，使用像Blend for Visual Studio这样的GUI 编辑器？

@sim756

我知道。 有时我们确实会写 new Button() { .... }

有时人们在不接触 XAML 的情况下编写整个 XF 应用程序 - 他们对此感到高兴;-)。

@sim756

我知道。 有时我们确实会写 new Button() { .... }

有时人们在不接触 XAML 的情况下编写整个 XF 应用程序 - 他们对此感到高兴;-)。

@aspnetde

我很惊讶..！！ 😢

然而，不是因为他们，而是像我这样想要Blend for Xamarin/MAUI 的人不高兴：

Android Studio动作编辑器

https://developer.android.com/studio/write/motion-editor

@ sim756我想知道一旦您在具有正常热重载功能的系统中工作后，您是否仍然希望获得混合支持。 通常人们更喜欢那个

来自 XAML / Blend 背景，我对代码中 UI 的最初想法是后退，但一旦我尝试过，我发现有很多我根本没有考虑过的好处。 不再需要——现在看起来非常复杂但在当时感觉完全合理——诸如转换器、资源和类似的功能让我真正相信代码优先的 UI。

好吧，我们有 .designer.cs，但我们不必在那里编辑代码，即使我猜许多 Windows 窗体开发人员甚至从未见过 .designer.cs 文件的内容。

@ sim756 - 虽然一个有能力的设计师听起来是一个很棒的生产力工具，但如果你已经工作了一段时间，你可能已经在“遗留”代码库上工作，在那里设计师已经被破坏并停止工作几个 Visual Studio 版本，并且您必须手动理解和编辑 .designer.cs 中的数千行。 由于在此类代码库中进行最微小的更改（例如对齐按钮）可能需要一两天的时间 - 所有这些生产力优势都需要重新考虑。 （之前有使用 WinForms 和 WebForms 的经验）。

谈到 XAML， @dsyme在这个关于 Fabulous 的演讲中谈到了对重型工具的依赖，其中有一节专门介绍了“XAML 的问题”。 尽管 Fabulous 本身有很多问题，但仍然很难不同意提出的许多观点。