Flutter 最佳架构模式

Question

我来自 MVC 和 VIPER 世界，现在我是 Flutter 跨平台开发的新手。我真的很喜欢它带来的声明性的东西(例如 SwiftUI 也是如此)。我在 React 架构中看到了很多优势，Flutter 使用它来使用最新数据更新 UI。虽然我仍然试图理解小部件的概念。在我看来，单词小部件更多是关于 UI 的东西，但文档说 Flutter 中的所有东西都是小部件。
让我强调一个简单的例子。另外，让我们忘记声明式 UI 的事情。
在使用 Objective-C 或 Swift 的 iOS 世界中，我们通常会分离很多层，例如数据层、UI 层、服务层、一些辅助层等。
正如您可能注意到的，我们不能简单地将这些层称为小部件，但看起来像 flutter 可以，但我可能错了。
在 iOS 世界中，我想使用 VIPER 或一些类似的架构模式来分隔不同的层或添加一些服务来为我请求一些数据或将其保存到数据库中。
我可以使用哪些类似的方法或架构模式来遵循最佳实践建议以达到最佳结果，因为对于我来说，如果我们调用一些将数据作为小部件保存到数据库的服务，那就有点奇怪了。我想称之为更多的服务而不是一个小部件。
我是否需要为所有这些东西编写一个小部件？还是我弄错了？

Answer 1

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

首先让我说，flutter 足够灵活，可以让您采用以前使用过的任何模式，也可以从 MVVM、MVC、Redux、Mobx、Bloc、Provider、Riverpod 等 pp 那里获得许多模式，您可以依靠.
问:所有服务都必须是小部件吗？
答:这取决于。
先说“获取”服务(依赖注入(inject))
使用 Widgets 只是在 Flutter 中进行依赖注入(inject)的一种方式，它具有被限定的巨大好处(仅适用于小部件的子部件)，并且在不再需要小部件树的这一部分时被释放(有点过于简化) )。
还有其他像 getIt 这样不依赖于小部件树的 DI 系统——你可以用 getIt 做一些奇特的事情，这在许多依赖构建上下文来提供对对象的访问的其他系统中是很麻烦的。
恕我直言，在大多数情况下，您不希望将逻辑/服务放在小部件中，而是在一个单独的类中，然后通过小部件“提供”(例如，使用 Provider，或通过 getIt 将其注入(inject)小部件)。
关于“最佳实践”:
有许多很酷的模式，它们都有其优点和缺点。
如果你有一个大团队或者开发人员经常变化，你可能想要使用更严格和有偏见的系统，比如 BLOC(使用 bloc 库)——如果你是独奏或有足够的时间做你自己的研究，有可能是更适合您需求的模式。这个问题没有一个万能的答案。
为了进一步研究，我会指向 Flutter Architecture samples和相应的 Github repo, there might be more examples in the Pull Request section