基于 Flutter × OpenHarmony 的个人理财助手 App —— 构建全应用变量与数据结构

前言

在移动应用开发中，很多初学者往往把重心放在 UI 界面与交互效果上，却忽略了一个更基础、也更关键的问题：数据结构与全局状态设计。
尤其是在个人理财类应用中，数据模型的合理性直接决定了后期功能扩展的难易程度，比如统计分析、图表展示、数据同步等。

本文将基于 Flutter × OpenHarmony 跨端开发场景，以一个「个人理财助手 App」为例，重点讲解如何在项目早期阶段构建清晰、可扩展的 全应用变量与数据结构体系。

背景

个人理财类应用通常具备以下核心特征：

• 数据类型多：支出、收入、预算、统计
• 业务逻辑强：分类、筛选、时间维度分析
• 状态长期存在：本地存储、云同步
• 需要跨端：手机、平板、鸿蒙设备

在 Flutter × OpenHarmony 场景下，如果数据模型设计混乱：

• 后期统计模块会非常痛苦
• UI 状态管理会变得复杂
• 很难对接数据库（Hive / SQLite / ObjectBox 等）

因此，一个成熟的项目必须 先设计数据结构，再写页面逻辑。

Flutter × OpenHarmony 跨端开发介绍

Flutter 负责：

• UI 渲染
• 状态管理
• 跨平台逻辑复用

OpenHarmony 负责：

• 系统能力调用
• 分布式能力
• 本地数据存储
• 多设备协同

整体架构上属于：

Flutter 做表现层，OpenHarmony 提供系统级能力支撑。

在这种模式下，Flutter 层的数据模型基本可以做到 100% 复用，这正是我们本文要解决的问题：
如何设计一套稳定、清晰、通用的数据结构体系？

开发核心代码（详细解析）

一、功能模块枚举设计

/// 理财功能模块枚举
enum FinanceModule {
  expenses,     // 支出记录
  income,       // 收入记录
  budget,       // 预算管理
  statistics,   // 财务统计
}

设计意义

这个枚举的本质是：全应用一级功能路由状态。

它通常用于：

• 底部导航栏切换
• 页面 Tab 切换
• 状态机控制当前页面展示内容

优点：

• 避免 magic string（字符串判断）
• 编译期安全
• 方便后期增加新模块（如：资产、负债）

二、业务分类枚举（领域建模）

支出分类

enum ExpenseCategory {
  food,
  transportation,
  shopping,
  entertainment,
  housing,
  utilities,
  education,
  health,
  other,
}

收入来源

enum IncomeSource {
  salary,
  bonus,
  investment,
  freelance,
  gift,
  other,
}

设计思想：领域驱动设计（DDD）

这类枚举属于 领域模型（Domain Model）：

• 它们不是 UI 概念
• 而是业务世界的真实抽象

后期用途非常多：

• 图表统计分组
• 饼图维度
• 预算分类绑定
• 数据库索引字段

三、支出数据模型设计

class ExpenseRecord {
  final String id;
  final double amount;
  final ExpenseCategory category;
  final DateTime date;
  final String description;
  final bool isRecurring;
  final String paymentMethod;
}

字段解析

设计亮点

这是一个标准不可变数据模型（Immutable Model）：

• 所有字段 final
• 构造函数一次性赋值
• 天然适合做状态管理（Provider / Riverpod / Bloc）

四、收入数据模型

class IncomeRecord {
  final String id;
  final double amount;
  final IncomeSource source;
  final DateTime date;
  final String description;
  final bool isRecurring;
  final String paymentMethod;
}

结构与 ExpenseRecord 高度一致。

这是一个非常重要的工程经验：

同类数据结构保持“对称设计”，后期统计与复用成本极低。

例如：

• 可以写统一统计函数：

  • List<T extends FinancialRecord>

• 方便抽象父类（如后期重构）

五、预算模型（包含业务计算逻辑）

class Budget {
  final String id;
  final ExpenseCategory category;
  final double budgetAmount;
  final double spentAmount;
  final DateTime startDate;
  final DateTime endDate;

  double get remainingAmount => budgetAmount - spentAmount;

  double get usagePercentage => (spentAmount / budgetAmount) * 100;
}

这是本文最关键的设计点

预算模型不只是“数据容器”，而是：

业务模型 + 行为封装

double get remainingAmount
double get usagePercentage

这种写法属于 富模型设计（Rich Model）：

• 把业务逻辑写进模型
• 页面层只负责展示
• 彻底解耦 UI 与计算逻辑

这是企业级项目非常推荐的模式。

六、全局状态变量设计

class _SearchPageState extends State<SearchPage> {
  FinanceModule _currentModule = FinanceModule.expenses;

  List<ExpenseRecord> _expenses = [];
  List<IncomeRecord> _income = [];
  List<Budget> _budgets = [];

  String _searchKeyword = '';
  final TextEditingController _searchController = TextEditingController();
}

这是一个标准的“应用状态中心”

本质上它就是一个 轻量级状态仓库（State Store）。

后期可无缝升级为：

• Provider
• Riverpod
• Bloc
• GetX
• Redux

数据模型完全无需修改。

心得

通过这个案例可以发现一个非常重要的工程原则：

数据结构设计质量，决定项目 70% 的上限。

优秀的数据模型具备以下特征：

1. 与业务高度一致（领域建模）
2. 枚举替代字符串
3. 不可变对象（final）
4. 模型内部封装业务逻辑
5. 支持统计、扩展、持久化

很多项目后期难以维护，本质不是 Flutter 写得不好，而是：

一开始数据结构就设计错了。

总结

在 Flutter × OpenHarmony 跨端开发中，个人理财类应用的核心并不在 UI，而在 数据模型与全局状态设计。
通过枚举定义领域边界，通过不可变模型承载业务数据，通过富模型封装计算逻辑，可以构建一套高度可扩展、易维护、适配多端的应用基础架构。

一句话总结：

先设计好数据世界，再去搭建界面世界，这是所有高质量应用的共同规律。