滕州营销型网站网站设计规范

滕州营销型网站,网站设计规范,芜湖有哪些招聘网站,做网站 怎么赚钱分层领域模型规约领域模型本身有没固定的使用限制#xff0c;但是在一套项目架构体系中需要有统一的规范。领域对象描述#xff1a;DO#xff08;Data Object#xff09;#xff1a;此对象与数据库表结构一一对应#xff0c;通过 DAO 层向上传输数据源对象。DTO#xff…分层领域模型规约领域模型本身有没固定的使用限制但是在一套项目架构体系中需要有统一的规范。领域对象描述DOData Object此对象与数据库表结构一一对应通过DAO层向上传输数据源对象。DTOData Transfer Object数据传输对象Service 或 Manager 向外传输的对象。BOBusiness Object业务对象可以由 Service 层输出的封装业务逻辑的对象。Query数据查询对象各层接收上层的查询请求。注意超过2个参数的查询封装禁止使用Map类来传输。VOView Object显示层对象通常是 Web 向模板渲染引擎层传输的对象。各层之间的关系如下图所示里面包含了领域模型的传递过程。分层领域模型的核心是给不同环节的 “数据” 分角色、定规矩就像开一家外卖店不同岗位后厨、配送、前台用不同的 “单据”只包含自己需要的信息不冗余、不混乱。下面用「外卖平台」这个生活场景把每个概念讲透先记核心逻辑不同 “对象” 对应外卖店不同的 “单据 / 本子”只干自己的活数据不混用。表格模型名称通俗理解外卖店场景核心作用DO原始档案本存数据库原始数据和表结构一一对应DTO配送员的配送单跨环节传数据只带需要的信息BO后厨的订单处理单封装业务规则服务层内部用Query前台的查询小票封装查询条件避免参数混乱VO用户 App 的订单详情页给前端展示数据做 “美化 / 简化”1. DOData Object数据对象 → 外卖店的「原始档案本」通俗解释就像外卖店的 “顾客档案本”每一页只记数据库里的原始信息格式和数据库表完全一致没有任何加工、删减。比如档案本里只记顾客 ID、姓名、电话、地址、会员等级和数据库customer表的字段一一对应多一个字都不写少一个字也不行。实际案例假设外卖平台数据库里有个customer表字段是id顾客 ID、name姓名、phone电话、address地址、vip_level会员等级。那么代码里的CustomerDO对象就长这样新手不用管语法看属性就行cpp运行// CustomerDO和数据库表字段完全对应只存原始数据 class CustomerDO { private: int id; // 对应表的id字段 string name; // 对应表的name字段 string phone; // 对应表的phone字段 string address; // 对应表的address字段 int vip_level; // 对应表的vip_level字段 // 只有“存/取”这些数据的方法没有任何业务逻辑 };谁用只有 DAO 层相当于 “管档案本的店员”会用 DO比如从数据库查顾客信息时把表的一行数据转成 CustomerDO只做 “原始数据搬运”不加工。2. DTOData Transfer Object数据传输对象 → 外卖店的「配送单」通俗解释配送员不需要看顾客的会员等级、档案 ID只需要 “姓名、电话、地址、菜品、配送时间”—— 这些信息来自「顾客档案本CustomerDO」「订单档案本OrderDO」是专门为 “传输” 给配送员准备的单据只包含需要的信息去掉冗余。实际案例用户下单后后端需要把订单信息传给配送系统就做一个OrderDTOcpp运行// OrderDTO只包含配送系统需要的信息冗余信息全删掉 class OrderDTO { private: string customerName; // 顾客姓名来自CustomerDO string customerPhone; // 顾客电话来自CustomerDO string address; // 配送地址来自CustomerDO string dishName; // 菜品名称来自OrderDO string deliveryTime; // 配送时间来自OrderDO // 没有会员等级、订单支付金额配送员不需要 };为什么要用比如配送系统只需要 5 个信息若直接传 CustomerDOOrderDO共 10 个字段会多传 5 个无用信息浪费网络 / 内存DTO 只传需要的效率更高。3. BOBusiness Object业务对象 → 外卖店的「订单处理单」通俗解释后厨总管Service 层处理订单时用的 “内部单据”不仅包含原始档案信息还加了业务逻辑处理后的结果。比如原始信息顾客姓名、订单金额、会员等级业务处理结果“是否免配送费会员免”“预计送达时间按距离算”。BO 是 “服务层自己用的”不会传给前端 / 配送员只用来处理业务规则。实际案例cpp运行// OrderBO包含原始数据业务处理结果供服务层内部使用 class OrderBO { private: // 原始数据来自DO CustomerDO customer; // 顾客原始信息 OrderDO order; // 订单原始信息 // 业务处理后的结果 bool isFreeDelivery; // 是否免配送费会员等级≥2则免 string expectedTime; // 预计送达时间按地址距离计算 // 业务逻辑方法判断是否免配送费 void calculateFreeDelivery() { if (customer.getVipLevel() 2) { isFreeDelivery true; } else { isFreeDelivery false; } } };谁用只有 Service 层后厨总管用比如算配送费、安排出餐顺序都基于 BO 里的业务逻辑。4. Query数据查询对象 → 外卖店的「查询小票」通俗解释顾客来问 “我想查近 7 天、朝阳区、点过麻辣烫的订单”前台店员Controller 层不会拿一堆零散纸条多个参数而是写在统一格式的小票Query上字段就是 “时间范围、区域、菜品类型”清晰不混乱。实际案例如果不用 Query查询方法要传 4 个参数startTime、endTime、area、dishType容易漏 / 乱封装成OrderQuery就清晰了cpp运行// OrderQuery封装所有查询条件参数再多也不乱 class OrderQuery { private: string startTime; // 开始时间近7天 string endTime; // 结束时间 string area; // 区域朝阳区 string dishType; // 菜品类型麻辣烫 };新手注意超过 2 个查询参数就用 Query别用 Map比如MapString, String——Map 没有固定格式新人维护时不知道里面有啥参数容易出错。5. VOView Object显示层对象 → 外卖 App 的「订单详情页」通俗解释用户在 App 上看到的 “订单详情”是专门做了 “美化 / 简化” 的信息。比如数据库里存的 “配送状态码 1”VO 里改成 “骑手已接单正在赶来”数据库里的 “时间戳 1718901234”VO 里改成 “18:30还有 15 分钟”VO 只给用户看数据都是 “人话”没有原始编码 / 乱码。实际案例cpp运行// OrderVO给App前端展示的信息全是用户能看懂的 class OrderVO { private: string orderNo; // 订单号格式化20240620123456 string dishName; // 菜品名称 string deliveryStatus; // 配送状态“骑手已接单”而非数字1 string expectedTime; // 预计送达时间“18:30”而非时间戳 string address; // 配送地址隐藏门牌号后两位保护隐私 };谁用前端App / 网页用后端把 BO/DTO 的数据加工成 VO传给前端展示。用「外卖订单流程」串起所有模型新手必看用户在 App 上查订单输入 “近 7 天、朝阳区、麻辣烫”→ 前台店员Controller把条件封装成OrderQuery传给后厨总管Service后厨总管让档案员DAO从数据库拿CustomerDO顾客档案、OrderDO订单档案后厨总管把 DO 封装成OrderBO处理业务逻辑比如判断会员是否免配送费后厨总管从 BO 里挑出配送员需要的信息做成OrderDTO传给配送系统同时后厨总管把 BO 里的信息加工成OrderVO比如把状态码转成 “骑手已接单”传给 App 前端用户看到易懂的订单详情。新手总结为什么要搞这些 “对象”就像外卖店不分岗位会乱套管档案的去送外卖配送员去做账代码不分模型也会乱若直接把 DO 传给前端会泄露用户隐私比如会员等级、支付金额若不用 Query查询参数多了容易漏传 / 传错若不用 BO业务逻辑会散在各处新人改代码时找不到在哪改。简单说每个对象只干自己的活数据不混用新手维护时一眼就知道 “改 VO 是改前端显示改 DO 是改数据库数据”不会懵。