Flutter 最佳架构模式

Question

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

Let me highlight a simple example. Also, let's forget about declarative UI things.

In the iOS world using Objective-C or Swift, we usually separate a lot of layers such as data layer, UI layer, service layer, some helper layers and etc.

As you may notice we can't simply call these layers widgets, but looks like flutter can, but I may be wrong.

In the iOS world, I would like to use VIPER or some similar architecture pattern to separate different layers or add some services which request some data for me or do save it into the database.

What are the similar approaches or architecture patterns which I can use to follow best practice recommendations to achieve the best result, because as for me if we call some service which saves data to the database as a widget it's a bit strange. I would like to call it more service rather than a widget.

Do I need to write a widget for all such things? Or did I get it wrong?

Answer 1

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

首先我要说的是，flutter 足够灵活，允许您采用以前使用过的任何模式，包括 MVVM、MVC、Redux、Mobx、Bloc、Provider、Riverpod 等，有很多模式可供您依赖。

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

答：这要看情况。

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

使用 Widgets 只是 Flutter 中进行依赖注入的一种方式，它的巨大好处是可以限定作用域（仅适用于 widget 的子级），并且当不再需要 widgettree 的这一部分时可以将其释放（有点过于简化） ）。

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

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

关于“最佳实践”：

有许多很酷的模式，它们都有各自的优点和缺点。

如果你有一个大团队或者开发人员经常变化，你可能想要使用更严格和有偏见的系统，例如 BLOC（使用 bloc 库） - 如果你是独行者或有足够的时间进行自己的研究，那么可能是更适合您需求的模式。对于这个问题，没有一刀切的答案。

为了进一步研究，我将指向Flutter Architecture 示例和相应的Github 存储库，Pull Request 部分中可能有更多示例