Flutter最佳架构探究

背景
作为最近很火的一个跨平台技术，以其高性能、跨平台的一系列优秀特性成功吸引了很多开发者和组织的青睐，但是由于其不同于传统或iOS开发的机制，使得视图的代码往往冗长、不够简洁，解决这种困境的方法就是在开发中合理地运用合适的架构模式，使得程序的视图与数据分离，这样视图层的代码只用专心进行视图的描述和操作即可，不涉及过多复杂的数据操作，这样就可以使视图层的代码达到简洁。由于目前没有官方推荐的项目架构，而且笔者也未遇到大家都说好用的架构模式，故此，笔者基于MVP的架构，设计了一套我个人比较青睐的架构模式，本文将详细介绍，希望可以和大家一起沟通、探索，力争衍生出一套适合的架构模式，从而大大提高生产力，如果文中有什么地方大家觉得设计的不合理的，大可提出，我们一起讨论。
从实例看模式
本文将基于一个经典的登录/注册需求展开描述，将登录/注册的界面与逻辑分离，以求达到解耦，我们首先想想，对于一个注册/登录需求，按照传统MVP的思想，应该如何将其视图与逻辑分离，大致的流程应该是这样的：
IView、、三个接口分别是View、、Model类应该实现（）的接口View类中持有类的实例，记做（实际上是类的实例，因为类实现了接口），当View中的登录按钮被点击时，调用对象的登录方法类中持有IView和类的实例，记做iView和（实际上是View类和Model类的实例，因为View类和Model类分别实现了IView接口和接口），当的登录方法被调用时，调用对象的登录方法Model类持有的实例，记做（实际上是类的实例，因为类实现了接口），Model类的登录方法被调用后，进行网络操作，发起登录请求，获取登录的结果（成功或失败），并调用对象的方法将结果回调给层接收到Model的回调之后调用iView对象的回调方法，将结果继续回调给View层进而实现视图更新，整个操作完成
总结一下，IView、、三个接口分别应该包含的方法如下：
IView：登录/注册操作、结果回调操作
：登录/注册操作、结果回调操作
：登录/注册操作
可以看到，IView、、三个接口都具有登录/注册操作，而IView、都具有结果回调操作，这样在定义接口的时候，登录/注册操作的声明会被写3遍、结果回调操作的声明会被写2遍，代码上会出现臃肿和冗余。所以我对此进行了改进，改进示意图如下：
【Flutter最佳架构探究】

文章插图
将登录/注册操作这类M、V、P都应该具有的操作抽取到这个接口中，然后让IView、、这三个接口实现（）这个接口，将结果回调操作抽取到这个接口中，让IView、这两个接口实现（）这个接口，然后，让View实现（）IView接口，让实现（）这个接口，让Model实现（）这个接口，这样，一个登录操作的完成流程是这样的：

文章插图
View类持有类的实例，记做（实际上是类的实例，因为类实现了接口），当View中的登录按钮被点击时，调用对象的登录方法类中持有IView和类的对象，记做iView和（实际上是View类和Model类的实例，因为View类和Model类分别实现了IView接口和接口），当类的登录方法被调用时，调用对象的登录方法Model类持有类的实例，记做（实际上是类的实例，因为类实现了接口，而接口实现了接口），Model类的登录方法被调用后，进行网络操作，发起登录请求，获取登录的结果（成功或失败），并调用对象的回调方法将结果回调给接收到Model的回调之后调用iView对象的实例，将结果继续回调给View层进而实现视图更新，整个操作完成