北京 网站建设,甘肃系统建站怎么用,找做网站技术人员,平顶山营销型网站建设子玥酱 #xff08;掘金 / 知乎 / CSDN / 简书 同名#xff09; 大家好#xff0c;我是 子玥酱#xff0c;一名长期深耕在一线的前端程序媛 #x1f469;‍#x1f4bb;。曾就职于多家知名互联网大厂#xff0c;目前在某国企负责前端软件研发相关工作#xff0c;主要聚…子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、很多项目只有“文件夹结构”二、典型的依赖混乱案例三、组件也开始写业务逻辑四、页面变成“超级控制器”五、真正的依赖管理是什么六、正确的模块职责PageServiceRepositoryNetwork七、组件应该保持“无业务”八、依赖失控的典型信号1、页面文件超过 1500 行2、Service 互相调用3、组件调用 API4、修改一个模块影响很多地方总结引言很多开发者在做鸿蒙应用时一开始项目都很简单。可能只有几个页面Login Home Profile代码结构也很直观pages components utils项目可以快速跑起来功能也很快能完成。但当项目逐渐变大功能越来越多时很多团队都会遇到一个问题代码越来越乱。很多时候大家会以为是代码写得不好项目复杂度太高但真正的问题往往只有一个没有真正的依赖管理。一、很多项目只有“文件夹结构”很多项目看起来结构很清晰entry ├─ pages ├─ components ├─ services ├─ models └─ utils但仔细看代码会发现pages → services services → pages components → services services → components依赖关系其实是所有模块互相引用结构虽然看起来是分层的但实际上完全没有依赖规则。换句话说只是把代码放进不同文件夹而已。这不叫架构。二、典型的依赖混乱案例很多鸿蒙项目很容易变成这样HomePage ├─ 调用 UserService ├─ 调用 OrderService └─ 调用 PaymentService然后OrderService └─ 调用 UserService接着UserService └─ 调用 OrderService于是依赖变成UserService ↔ OrderService循环依赖出现一旦发生这种情况重构困难模块无法拆分修改风险极高三、组件也开始写业务逻辑很多项目还会出现另一种问题组件直接依赖 Service。例如Componentstruct UserCard{asyncloadUser(){letservicenewUserService()this.userawaitservice.getUser()}}这样组件就变成UI 业务逻辑组件本来应该是可复用 UI结果却变成业务组件复用性直接消失。四、页面变成“超级控制器”如果依赖关系没有控制页面通常会变成这样HomePage ├─ 用户信息 ├─ 推荐内容 ├─ 广告 ├─ 订单状态 └─ 活动信息代码可能会长这样aboutToAppear(){this.loadUser()this.loadOrders()this.loadAds()this.loadRecommend()}页面逐渐变成UI 网络请求 数据处理 业务逻辑最后文件可能变成HomePage.ets 2000 行这就是典型的巨型页面文件。五、真正的依赖管理是什么真正的依赖管理其实只有一个核心原则依赖必须单向流动。推荐结构Page ↓ Service ↓ Repository ↓ Network也就是说UI → 业务 → 数据 → 网络绝对不能出现Network → Page或者Service → Page六、正确的模块职责如果依赖关系设计正确每一层职责非常清晰。Page只负责 UI例如EntryComponentstruct UserPage{service:UserServicenewUserService()asyncloadUser(){constuserawaitthis.service.getUser()this.nameuser.name}}Service负责业务逻辑。exportclassUserService{repo:UserRepositorynewUserRepository()asyncgetUser(){returnawaitthis.repo.fetchUser()}}Repository负责数据来源。exportclassUserRepository{client:HttpClientnewHttpClient()asyncfetchUser(){returnawaitthis.client.get(/user)}}Network负责网络请求。exportclassHttpClient{asyncget(url:string){...}}依赖关系变成Page → Service → Repository → Network非常清晰。七、组件应该保持“无业务”组件只负责 UI例如Componentexportstruct UserCard{Propname:stringbuild(){Text(this.name)}}组件不应该调用 API 操作 Service 处理业务否则组件就无法复用。八、依赖失控的典型信号如果项目出现以下情况大概率依赖管理已经失控1、页面文件超过 1500 行说明UI 业务逻辑混在一起2、Service 互相调用例如UserService → OrderService OrderService → UserService3、组件调用 API说明 UI 和业务没有分离。4、修改一个模块影响很多地方说明模块耦合严重。总结很多鸿蒙 App 项目虽然有目录结构pages services components但实际上只是文件分类并没有真正的依赖管理。真正的依赖管理需要遵循一个原则依赖单向流动推荐结构Page → Service → Repository → Network同时保持Component → 纯 UI Service → 业务逻辑 Repository → 数据来源只要依赖关系设计正确项目会有几个明显变化页面代码更简单模块更容易复用项目更容易维护简单来说就是一句话架构不是目录结构而是依赖关系。