Flutter 项目架构技术指南

简介: 探讨Flutter项目代码组织架构的关键方面和建议。了解设计原则SOLID、Clean Architecture,以及架构模式MVC、MVP、MVVM,如何有机结合使用,打造优秀的应用架构。

Flutter 项目架构技术指南

视频

https://www.bilibili.com/video/BV1rx4y127kN/

前言

原文 https://ducafecat.com/blog/flutter-clean-architecture-guide

探讨Flutter项目代码组织架构的关键方面和建议。了解设计原则SOLID、Clean Architecture,以及架构模式MVC、MVP、MVVM,如何有机结合使用,打造优秀的应用架构。

参考

https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://developer.mozilla.org/en-US/docs/Glossary/MVC

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

https://zh.wikipedia.org/zh-hant/MVVM

SOLID 原则

SOLID 原则

SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)是由罗伯特·C·马丁在21世纪早期引入,指代了面向对象编程和面向对象设计的五个基本原则。

在 Flutter 中遵循 SOLID 设计原则具有重要性,因为这些原则有助于提高代码质量、可维护性和可扩展性,同时降低代码的复杂度和耦合度。

  1. 单一职责原则 (Single Responsibility Principle)

    每个类应该只有一个责任。在 Flutter 中,您可以将不同功能拆分为不同的小部件(widget),每个小部件负责特定的 UI 展示或交互逻辑。

    // 单一职责原则示例:一个负责显示用户信息的小部件
    
    class UserInfoWidget extends StatelessWidget {
         
         
      final User user;
    
      UserInfoWidget(this.user);
    
      
      Widget build(BuildContext context) {
         
         
        return Column(
          children: [
            Text('Name: ${user.name}'),
            Text('Age: ${user.age}'),
          ],
        );
      }
    }
    
  2. 开闭原则 (Open/Closed Principle)

    软件实体应该对扩展开放,对修改关闭。在 Flutter 中,您可以通过使用组合、继承和多态来实现这一原则。例如,通过创建可重用的小部件并根据需要进行扩展,而不是直接修改现有代码。

    // 开闭原则示例:通过继承实现可扩展的主题切换功能
    
    abstract class Theme {
         
         
      ThemeData getThemeData();
    }
    
    class LightTheme extends Theme {
         
         
      
      ThemeData getThemeData() {
         
         
        return ThemeData.light();
      }
    }
    
    class DarkTheme extends Theme {
         
         
      
      ThemeData getThemeData() {
         
         
        return ThemeData.dark();
      }
    }
    
  3. 里氏替换原则 (Liskov Substitution Principle)

    子类应该能够替换其父类并保持行为一致。在 Flutter 中,确保子类可以替换父类而不会引起意外行为是很重要的。继承关系应该是 is-a 的关系,而不是 has-a 的关系。

    // 里氏替换原则示例:确保子类可以替换父类而不引起问题
    
    abstract class Shape {
         
         
      double getArea();
    }
    
    class Rectangle extends Shape {
         
         
      double width;
      double height;
    
      
      double getArea() {
         
         
        return width * height;
      }
    }
    
    class Square extends Shape {
         
         
      double side;
    
      
      double getArea() {
         
         
        return side * side;
      }
    }
    
  4. 接口隔离原则 (Interface Segregation Principle)

    客户端不应该被迫依赖它们不使用的接口。在 Flutter 中,您可以根据需要创建多个接口,以确保每个接口只包含客户端所需的方法。

    // 接口隔离原则示例:将接口细分为更小的接口
    
    abstract class CanFly {
         
         
      void fly();
    }
    
    abstract class CanSwim {
         
         
      void swim();
    }
    
    class Bird implements CanFly {
         
         
      
      void fly() {
         
         
        print('Bird is flying');
      }
    }
    
    class Fish implements CanSwim {
         
         
      
      void swim() {
         
         
        print('Fish is swimming');
      }
    }
    
  5. 依赖反转原则 (Dependency Inversion Principle)

    高层模块不应该依赖于低层模块,二者都应该依赖于抽象。在 Flutter 中,您可以通过依赖注入、接口抽象等方式实现依赖反转,以减少模块之间的耦合度。

    // 依赖反转原则示例:通过依赖注入实现依赖反转
    
    class UserRepository {
         
         
      Future<User> getUser() async {
         
         
        // Fetch user data from API
      }
    }
    
    class UserBloc {
         
         
      final UserRepository userRepository;
    
      UserBloc(this.userRepository);
    
      Future<void> fetchUser() async {
         
         
        User user = await userRepository.getUser();
        // Process user data
      }
    }
    

Clean Architecture 原则

Clean Architecture

在 Flutter 开发中,Clean Architecture(CA)清晰架构是一种软件架构设计模式,旨在将应用程序分解为不同的层级,每一层级都有明确定义的职责,以实现代码的可维护性、可测试性和可扩展性。Clean Architecture 通过明确定义各层之间的依赖关系,将业务逻辑与框架、库和外部依赖分离开来,从而使代码更加灵活和独立。

示例中其中包括实体层、数据层、领域层和表示层。

实体层(Entities):

// 实体类
class User {
   
   
  final String id;
  final String name;

  User({
   
   required this.id, required this.name});
}

数据层(Data Layer):

// 数据接口
abstract class UserRepository {
   
   
  Future<User> getUserById(String userId);
}

// 数据实现
class UserRepositoryImpl implements UserRepository {
   
   
  
  Future<User> getUserById(String userId) {
   
   
    // 实现获取用户逻辑
  }
}

领域层(Domain Layer):

// 用例类
class GetUserByIdUseCase {
   
   
  final UserRepository userRepository;

  GetUserByIdUseCase(this.userRepository);

  Future<User> execute(String userId) {
   
   
    return userRepository.getUserById(userId);
  }
}

表示层(Presentation Layer):

// Flutter 页面
class UserPage extends StatelessWidget {
   
   
  final GetUserByIdUseCase getUserByIdUseCase;

  UserPage(this.getUserByIdUseCase);

  
  Widget build(BuildContext context) {
   
   
    return Scaffold(
      appBar: AppBar(
        title: Text('User Page'),
      ),
      body: Center(
        child: FutureBuilder<User>(
          future: getUserByIdUseCase.execute('1'),
          builder: (context, snapshot) {
   
   
            if (snapshot.hasData) {
   
   
              return Text('User: ${snapshot.data!.name}');
            } else if (snapshot.hasError) {
   
   
              return Text('Error: ${snapshot.error}');
            }
            return CircularProgressIndicator();
          },
        ),
      ),
    );
  }
}

架构模式

软件架构模式,用于组织代码、分离关注点以及提高代码的可维护性和可测试性。常见模式有 Model-View-Controller(模型-视图-控制器)、Model-View-Presenter(模型-视图-展示器)和Model-View-ViewModel(模型-视图-视图模型)。

1. MVC(Model-View-Controller):

MVC

  • 模型(Model):代表应用程序的数据和业务逻辑。
  • 视图(View):负责展示数据给用户以及接收用户输入。
  • 控制器(Controller):处理用户输入、更新模型和视图之间的关系。

在 MVC 中,视图和控制器之间通过双向通信进行交互,控制器负责更新模型和视图。MVC 帮助将应用程序分解为三个独立的部分,以便更好地管理代码逻辑。

Model:

class UserModel {
   
   
  String id;
  String name;

  UserModel({
   
   required this.id, required this.name});
}

View:

class UserView extends StatelessWidget {
   
   
  final UserModel user;

  UserView(this.user);

  
  Widget build(BuildContext context) {
   
   
    return Text('User: ${user.name}');
  }
}

Controller:

class UserController {
   
   
  UserModel user = UserModel(id: '1', name: 'John Doe');
}

IOS 就是典型的 MVC 模式,通过事件触发控制器最后内部机制更新视图

2. MVP(Model-View-Presenter):

MVP

  • 模型(Model):同样代表应用程序的数据和业务逻辑。
  • 视图(View):负责展示数据给用户以及接收用户输入。
  • 展示器(Presenter):类似于控制器,负责处理用户输入、更新模型和更新视图。

在 MVP 中,视图和展示器之间通过接口进行通信,展示器负责从模型获取数据并更新视图。MVP 将视图和模型解耦,使得更容易进行单元测试和维护。

Model:

同上

View:

class UserView extends StatelessWidget {
   
   
  final UserModel user;
  final UserPresenter presenter;

  UserView(this.user, this.presenter);

  
  Widget build(BuildContext context) {
   
   
    return Column(
      children: [
        Text('User: ${user.name}'),
        ElevatedButton(
          onPressed: () {
   
   
            presenter.updateUserName();
          },
          child: Text('Update Name'),
        ),
      ],
    );
  }
}

Presenter:

class UserPresenter {
   
   
  UserModel user = UserModel(id: '1', name: 'John Doe');
  UserView view;

  UserPresenter(this.view);

  void updateUserName() {
   
   
    user.name = 'Jane Smith';
    view.updateView(user);
  }
}

Presenter 中有视图方法来更新

3. MVVM(Model-View-ViewModel):

MVVM

  • 模型(Model):同样代表应用程序的数据和业务逻辑。
  • 视图(View):负责展示数据给用户以及接收用户输入。
  • 视图模型(ViewModel):连接视图和模型,负责处理视图逻辑、数据绑定以及与模型的交互。

在 MVVM 中,视图模型充当了视图和模型之间的中介,负责处理大部分视图逻辑,同时通过数据绑定将视图与模型连接起来。MVVM 的目标是将视图的状态和行为与业务逻辑分离,以实现更好的可维护性和可测试性。

Model:

同上

View:

class UserView extends StatelessWidget {
   
   
  final UserViewModel viewModel;

  UserView(this.viewModel);

  
  Widget build(BuildContext context) {
   
   
    return Column(
      children: [
        Text('User: ${viewModel.user.name}'),
        ElevatedButton(
          onPressed: () {
   
   
            viewModel.updateUserName();
          },
          child: Text('Update Name'),
        ),
      ],
    );
  }
}

ViewModel:

class UserViewModel {
   
   
  UserModel user = UserModel(id: '1', name: 'John Doe');

  void updateUserName() {
   
   
    user.name = 'Jane Smith';
    notifyListeners();
  }
}

与 MVP 最大的区别是 MVVM 可以同时更新多个视图

Packages 优秀插件

freezed

https://pub-web.flutter-io.cn/packages/freezed

一个用于数据类 / 联合体 / 模式匹配 / 克隆的代码生成器。

详见 https://ducafecat.com/blog/flutter_application_freezed

get_it

https://pub-web.flutter-io.cn/packages/get_it

依赖管理工具包 懒加载、单例、依赖注入、作用域、注入管理... 。

详见 <在 getx 中使用 get_it 管理依赖注入> https://ducafecat.com/blog/use-get_it-in-getx

Equatable

https://pub-web.flutter-io.cn/packages/equatable

equatable 可以帮助开发人员轻松地重写类的 ==hashCode 方法,从而简化对象之间的相等性比较。

equatable 可以与状态管理、数据模型等方面结合使用,帮助开发人员更轻松地处理对象的相等性比较。

状态管理

  • Provider
  • Bloc
  • GetX
  • Riverpod

详见 <盘点主流 Flutter 状态管理库2024>https://ducafecat.com/blog/flutter-state-management-libraries-2024

小结

本文探讨了Flutter项目代码组织架构的关键方面,包括设计原则SOLID、Clean Architecture,以及架构模式MVC、MVP、MVVM的有机结合。通过本文的指导和建议,读者可以更好地了解如何打造优秀的Flutter应用架构,提高代码可维护性和扩展性。务必在实际项目中灵活运用这些架构原则,为应用的长期发展奠定坚实基础。

感谢阅读本文

如果有什么建议,请在评论中让我知道。我很乐意改进。


© 猫哥
ducafecat.com

end

相关文章
|
15天前
|
缓存 监控 前端开发
【Flutter 前端技术开发专栏】Flutter 应用的启动优化策略
【4月更文挑战第30天】本文探讨了Flutter应用启动优化策略,包括理解启动过程、资源加载优化、减少初始化工作、界面布局简化、异步初始化、预加载关键数据、性能监控分析以及案例和未来优化方向。通过这些方法,可以缩短启动时间,提升用户体验。使用Flutter DevTools等工具可助于识别和解决性能瓶颈,实现持续优化。
【Flutter 前端技术开发专栏】Flutter 应用的启动优化策略
|
13天前
|
运维 Oracle 容灾
Oracle dataguard 容灾技术实战(笔记),教你一种更清晰的Linux运维架构
Oracle dataguard 容灾技术实战(笔记),教你一种更清晰的Linux运维架构
|
15天前
|
SpringCloudAlibaba Dubbo 应用服务中间件
【微服务】微服务初步认识 - 微服务技术如何学习 · 认识微服务架构
【微服务】微服务初步认识 - 微服务技术如何学习 · 认识微服务架构
32 0
|
15天前
|
存储 设计模式 架构师
编码之道:从技术细节到系统架构的升华
【5月更文挑战第9天】 在编程的世界里,每一行代码都承载着功能与美学的双重使命。本文将探讨如何从关注技术细节出发,逐步深化对系统架构的理解,并在实践中实现从代码编写者到系统设计师的转变。通过分析具体案例,我们将揭示那些看似平凡的技术感悟如何在复杂系统的构建中发挥关键作用,以及这一过程中对软件开发者的启示。
24 3
|
2天前
|
监控 Devops API
构建高效微服务架构:API网关的作用与实践构建高效稳定的云基础设施:DevOps与容器化技术融合实践
【5月更文挑战第28天】 在当今的软件开发领域,微服务架构因其灵活性、可扩展性和容错能力而备受推崇。本文将深入探讨API网关在构建微服务系统中的关键角色,包括它如何促进系统的高可用性、安全性和性能监控。我们将剖析API网关的核心组件,并借助具体实例展示如何实现一个高效的API网关来服务于复杂的微服务环境。 【5月更文挑战第28天】 随着企业数字化转型的深入,传统的IT运维模式已难以满足快速迭代和持续交付的需求。本文聚焦于如何通过融合DevOps理念与容器化技术来构建一个高效、稳定且可扩展的云基础设施。我们将探讨持续集成/持续部署(CI/CD)流程的优化、基于微服务架构的容器化部署以及自动化监
|
2天前
|
运维 Kubernetes Cloud Native
构建高效云原生应用:采用微服务架构与容器化技术
【5月更文挑战第28天】 在当今数字化转型的浪潮中,企业正迅速采纳云原生技术以保持竞争力。本文深入探讨了构建高效云原生应用的关键要素,重点分析了微服务架构和容器化技术如何共同推动应用的敏捷性、可扩展性和可靠性。通过具体案例分析,揭示了这些技术在实际业务场景中的应用效果及其带来的显著改进。
|
3天前
|
监控 负载均衡 数据库
构建高效微服务架构:后端开发者的技术挑战与策略
【5月更文挑战第27天】 在数字化转型的浪潮中,微服务架构已成为软件开发的一大趋势。它通过拆分传统单体应用,实现服务的细粒度管理和独立部署,从而提高了系统的可扩展性和灵活性。然而,随之而来的是一系列技术挑战,包括服务治理、数据一致性、网络延迟等问题。本文将探讨这些挑战并提出相应的解决策略,以帮助后端开发者构建和维护一个高效的微服务系统。
|
6天前
|
弹性计算 编解码 运维
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨
基于「倚天710自研芯片+CIPU云原生基础设施处理器」组合的倚天ECS实例为解决算力挑战提供新思路。
|
6天前
|
运维 监控 小程序
一个人也能支撑起的项目是怎样的架构
云托管真的是开发者的福音!!!不仅简化了小程序API的接入,还省了买服务器的钱。像灰度发布、监控实例、服务器规格调整这些头疼的事儿,统统都不用费心。
47 2
|
7天前
|
弹性计算 编解码 运维
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨
阿里云、平头哥与Arm联合举办的飞天技术沙龙在上海举行,聚焦Arm Neoverse核心优势和倚天710计算实例在大数据、视频领域的应用。活动中,专家解读了倚天710的性能提升和成本效益,强调了CIPU云原生基础设施处理器的角色,以及如何通过软件优化实现资源池化和稳定性平衡。实例展示在视频编码和大数据处理上的性能提升分别达到80%和70%的性价比优化。沙龙吸引众多企业代表参与,促进技术交流与实践解决方案的探讨。
飞天技术沙龙回顾:业务创新新选择,倚天Arm架构深入探讨