SQLite 与 FreeSql ORM这是「从零搭建灌装监控系统」系列第9篇。监控数据不应该只停留在内存里这篇把 SQLite、FreeSql 和应用启动流程接起来让采集到的生产记录、报警记录可以查询、追溯也让后面的导出和日志查看有真正的数据来源。软件重启后昨天的记录去哪了现场第一次试跑的时候操作员问了我一个很朴素的问题“刚才那批数据能不能查”当时界面上的曲线和状态都还在程序也没有报错。可是软件一重启内存集合清空上一批记录就像没有发生过一样。监控程序如果只负责“现在显示什么”它更像一个仪表盘不像生产系统。我不想一上来就引入服务器数据库。灌装线上的单机部署、离线运行和维护成本都要求存储方案简单一点数据放在本地文件里程序自己创建表现场不用额外安装数据库服务。于是这一篇选择 SQLite 作为存储引擎FreeSql 作为访问层。这里的重点不是把 ORM 当成魔法而是把三个边界说清楚数据库什么时候初始化实体如何变成表业务服务如何使用同一个连接对象。为什么选 SQLite FreeSqlSQLite 是一个文件型数据库适合单机监控软件不需要独立的数据库服务一个.db文件就能随程序和配置一起管理支持事务、索引和常见查询备份时复制数据库文件即可部署简单。但直接拼 SQL 也有问题。生产记录、报警记录、系统日志都会有查询条件字符串拼接很快就会变成维护负担。FreeSql 提供了实体映射、分页、插入和查询能力代码表达的还是 C# 对象和查询条件。示例实体只保留教学需要的字段publicclassProductionRecord{[Column(IsIdentitytrue,IsPrimarytrue)]publiclongId{get;set;}publicDateTimeTime{get;set;}publicstringBatchNo{get;set;};publicdecimalVolume{get;set;}publicdecimalTemperature{get;set;}publicdoubleCycleTime{get;set;}publicstringOperator{get;set;};}真实项目里还有更多字段但文章里的实体要服务于解释不需要把每个设备寄存器都搬进来。字段越多读者越容易把注意力放到业务细节上而不是数据模型设计。DbProvider数据库入口只创建一次项目采用一个静态DbProvider作为数据库入口。它不负责业务查询只负责创建并暴露 FreeSql 实例。publicstaticclassDbProvider{privatestaticreadonlyobjectSyncRootnew();privatestaticIFreeSql?_fsql;publicstaticIFreeSqlFsql_fsql??thrownewInvalidOperationException(数据库尚未初始化);publicstaticvoidInitialize(stringconnectionString){if(_fsql!null)return;lock(SyncRoot){if(_fsql!null)return;_fsqlnewFreeSqlBuilder().UseConnectionString(DataType.Sqlite,connectionString).UseAutoSyncStructure(true).UseMonitorCommand((cmd,trace){LogService.Verbose($[SQL]{cmd.CommandText}\r\n -{trace});}).UseLazyLoading(false).Build();}}}这里有两个容易被忽略的细节。第一Fsql不应该在未初始化时返回 null。让调用点直接得到清晰异常比后面某个页面突然出现空引用更容易排查。第二Initialize使用双重检查。外层检查避免大多数调用进入锁锁内检查保证多线程启动时仍然只创建一个实例。数据库初始化往往发生在应用启动阶段但登录窗口、后台服务和主窗口初始化可能同时开始不能假设它一定只有一个线程。是否是否应用启动Fsql 已创建?直接返回进入 lockFsql 已创建?FreeSqlBuilder 构建实例AutoSyncStructure 同步表结构暴露 DbProvider.FsqlAutoSyncStructure 适合什么场景UseAutoSyncStructure(true)会根据实体结构同步数据表。开发阶段非常省事新增一个实体属性后重新启动程序表结构可以自动更新。但这不是完整的数据库迁移系统。生产环境的表结构变更如果涉及删除字段、数据转换或大表迁移不能只依赖自动同步。我的建议是学习项目和单机小工具可以打开自动同步发布版本要记录实体变更重要改动通过迁移脚本处理不要把测试数据库直接复制成正式数据库数据库路径放在工作目录或用户数据目录不要写死开发机路径。连接字符串应该由路径服务生成vardataDirectoryPath.Combine(workRoot,Data);Directory.CreateDirectory(dataDirectory);vardatabasePathPath.Combine(dataDirectory,filltrack.db);DbProvider.Initialize($Data Source{databasePath};);文章中的filltrack.db是示例名现场项目应当根据部署约定生成不能把开发机盘符、用户名或内部目录写进代码。业务服务只表达业务不重复造连接有了统一入口后数据服务可以很薄publicstaticclassDataService{publicstaticTaskSaveProductionRecordAsync(ProductionRecordrecord){returnDbProvider.Fsql.Insert(record).ExecuteAffrowsAsync();}publicstaticTaskListProductionRecordQueryAsync(DateTimestart,DateTimeend){returnDbProvider.Fsql.SelectProductionRecord().Where(xx.Timestartx.Timeend).OrderByDescending(xx.Time).ToListAsync();}}注意结束时间用了“小于”而不是把end直接写成“小于等于”。如果界面传入的是某一天的 00:00半开区间[start, end)更容易组合也不会因为毫秒精度造成边界重复。不要在每个服务里重新new FreeSqlBuilder()。那样做会产生多个连接管理器表结构同步、SQL 监控和事务边界都会变得混乱。服务可以是静态类也可以通过 DI 注册成单例关键是数据库访问入口要统一。SQL 监控不是为了炫技开发时打开 SQL 监控可以回答几个很实际的问题页面加载一次到底发了几条 SQL分页查询有没有真的使用LIMIT/OFFSET条件查询是否因为写法问题变成全表扫描某个按钮卡顿时是数据库慢还是设备通信慢.UseMonitorCommand((cmd,trace){if(DebugSettings.EnableSqlLog)LogService.Verbose($[SQL]{cmd.CommandText}\n{trace});})生产环境不建议把所有 SQL 都打到 UI 日志里。日志量太大时真正的报警反而会被淹没。可以让 SQL 监控由调试配置开关控制并且不要把密码、令牌等敏感值写入日志。事务边界要跟业务动作走一次灌装记录可能包含主记录、明细和统计数据。只插入主记录成功并不代表整批数据成功。简单场景下单表插入够用跨多表时要显式建立事务usingvarunitOfWorkDbProvider.Fsql.CreateUnitOfWork();try{unitOfWork.Orm.Insert(record).ExecuteAffrows();unitOfWork.Orm.Insert(detail).ExecuteAffrows();unitOfWork.Commit();}catch{unitOfWork.Rollback();throw;}事务不是“所有代码都包起来”。设备通信、等待用户操作、文件导出都不应该放在数据库事务里否则一个慢设备就能长时间锁住数据库。踩坑记录把数据库初始化放在页面构造函数页面可能被导航多次构造函数也可能重复执行。数据库初始化应该放在应用启动流程或核心服务初始化阶段页面只查询数据。自动同步当成版本迁移开发时加字段很舒服生产环境遇到字段删除、历史数据转换就不够了。正式发布前要明确数据库升级策略。查询时间条件包含边界错误“今天”的结束时间如果直接传当天 00:00会查不到当天数据。统一采用[start, end)调用方把结束时间传到下一天 00:00。把 SQL 全量打印到界面调试时很有用上线后会造成日志噪声。SQL 监控应当由调试开关控制日志级别也要区分。本篇小结问题做法数据保存在哪里SQLite 文件数据库ORM 如何创建FreeSql 实体模型如何保证单例双重检查 锁表结构怎么处理开发阶段 AutoSyncStructure生产阶段记录迁移数据访问放哪里DataService不在页面里直接写 SQL查询如何稳定统一时间半开区间必要时增加索引数据库接通以后下一步就是把采集到的条码变成真正的生产记录。否则数据库只是一个空壳。下期预告第10篇生产追溯条码触发自动记录下一篇从轮询数据里的条码变化开始讨论如何防止同一个条码被重复入库并把生产记录和当前设备状态关联起来。