Flutter 最佳架构模式答案

【问题标题】：Flutter best architecture patternsFlutter 最佳架构模式
【发布时间】：2020-12-19 23:26:58
【问题描述】：

我来自 MVC 和 VIPER 世界，现在我是 Flutter 跨平台开发的新手。我真的很喜欢它带来的声明性的东西（例如 SwiftUI 也一样）。我在 React 架构中看到了 Flutter 使用最新数据更新 UI 的许多优势。虽然我仍然试图理解小部件的概念。在我的脑海中，widget 这个词更多的是关于 UI 的东西，但是文档说 Flutter 中的所有东西都是一个小部件。

让我强调一个简单的例子。另外，让我们忘记声明性 UI 的事情。

在使用 Objective-C 或 Swift 的 iOS 世界中，我们通常会分离出很多层，例如数据层、UI 层、服务层、一些辅助层等。

您可能会注意到，我们不能简单地将这些层小部件称为小部件，但看起来 Flutter 可以，但我可能错了。

在 iOS 世界中，我想使用 VIPER 或一些类似的架构模式来分隔不同的层或添加一些服务来为我请求一些数据或将其保存到数据库中。

我可以使用哪些类似的方法或架构模式来遵循最佳实践建议以实现最佳结果，因为对于我来说，如果我们调用一些将数据作为小部件保存到数据库的服务，这有点奇怪。我想将其称为更多服务而不是小部件。

我需要为所有这些事情编写一个小部件吗？还是我弄错了？

【问题讨论】：

大家好，很久没有问这个问题了。你现在有什么想法吗？
我认为你不应该从字面上理解“一切都是小部件”。 Flutter 本身就是 UI 工具包。所以 UI 中的“一切”都是一个 Widget。这将更有意义。有一些小部件（如 InheritedWidget）有助于架构，但通常 Flutter 不关心业务逻辑。这将是纯粹的飞镖。就像在 iOS 中你有 UIKit 或 SwiftUI，但你的业务逻辑与 UIKit 和 SwiftUI 无关。（一切都是小部件意味着 UI 是基于小部件构建的，而 Android 则将活动、片段和视图作为基本 UI 元素）

标签： flutter

【解决方案1】：

我需要为所有这些事情编写小部件吗？还是我弄错了？

首先我要说的是，flutter 足够灵活，可以让您采用您之前使用过的任何模式，以及来自 MVVM、MVC、Redux、Mobx、Bloc、Provider、Riverpod 等的模式。您可以使用许多模式可以依靠。

问：所有服务都必须是小部件吗？

答：视情况而定。

让我们先谈谈“获取”服务（依赖注入）

使用 Widgets 只是在 Flutter 中进行依赖注入的一种方式，它具有巨大的好处，即作用域（仅对小部件的子级可用）以及在不再需要小部件树的这一部分时被释放（a有点过于简化了）。

还有其他 DI 系统，例如 getIt，它们不依赖于小部件树 - 您可以使用 getIt 做一些花哨的事情，这在许多其他依赖构建上下文来提供对对象的访问的其他 DI 系统中是很麻烦的.

恕我直言，在大多数情况下，您不希望将逻辑/服务放在小部件中，而是放在单独的类中，然后通过小部件“提供”（例如，使用 Provider，或通过 getIt 将其注入小部件）。

关于“最佳实践”：

有很多很酷的模式，它们各有优缺点。

如果您有一个大团队或开发人员经常更换，您可能希望使用更严格和有偏见的系统，例如 BLOC（使用 bloc 库） - 如果您是单人或有足够的时间自己动手做研究，可能会有更适合您需求的模式。这个问题没有万能的答案。

为了进一步研究，我会指出Flutter Architecture samples 和相应的Github repo, there might be more examples in the Pull Request section

【讨论】：