|
|
### 供需发布模块数据结构与功能分析
|
|
|
|
|
|
#### 一、数据结构
|
|
|
|
|
|
- **表：`supply_demands`（供需主表）**
|
|
|
- 字段：`id`, `user_id`, `title`, `type`(1=供应,2=需求), `content`, `tag`, `wechat`, `mobile`, `email`, `status`(0待审核/1通过/2拒绝/3退回修改/4永久隐藏), `view_count`, `contact_count`, `expire_time`, `public_way`(布尔，实际业务含义为1/2/3), `file_ids`(JSON), `contact_name`, `timestamps`, `deleted_at`
|
|
|
- 关系：
|
|
|
- `user`: 发布者（`hasOne User(id=user_id)`）
|
|
|
- `keeps`: 收藏（`hasMany SupplyDemandKeep(supply_demand_id=id)`）
|
|
|
- 虚拟属性：`files`（根据 `file_ids` 关联 `Upload` 列表）
|
|
|
|
|
|
- **表：`supply_demand_keeps`（收藏表）**
|
|
|
- 字段：`id`, `user_id`, `supply_demand_id`, `timestamps`, `deleted_at`
|
|
|
- 关系：
|
|
|
- `user`: 收藏者（`hasOne User(id=user_id)`）
|
|
|
- `supplyDemand`: 被收藏的供需（`hasOne SupplyDemand(id=supply_demand_id)`）
|
|
|
|
|
|
- **表：`dialogues`（会话表）**
|
|
|
- 字段：`id`, `user_id`, `to_user_id`, `supply_demand_id`, `last_content`, `last_datetime`, `timestamps`, `deleted_at`
|
|
|
- 关系：
|
|
|
- `user`: 会话发起方（`hasOne User(id=user_id)`）
|
|
|
- `toUser`: 会话接收方（`hasOne User(id=to_user_id)`）
|
|
|
- `supplyDemand`: 关联供需（`hasOne SupplyDemand(id=supply_demand_id)`）
|
|
|
|
|
|
- **表：`messages`（消息表）**
|
|
|
- 字段：`id`, `dialogue_id`, `user_id`, `to_user_id`, `supply_demand_id`, `content`, `is_read`, `timestamps`, `deleted_at`
|
|
|
- 关系：
|
|
|
- `user`/`toUser`: 发送方/接收方（`hasOne User`）
|
|
|
- `dialogue`: 所属会话（`hasOne Dialogue(id=dialogue_id)`）
|
|
|
- `supplyDemand`: 关联供需（`hasOne SupplyDemand(id=supply_demand_id)`）
|
|
|
|
|
|
- **表：`uploads`（附件表）**
|
|
|
- 字段：`id`, `belongs_type`, `belongs_id`, `original_name`, `folder`, `name`, `extension`, `size`, `creator_type`, `creator_id`, `timestamps`, `deleted_at`
|
|
|
- 用途：`supply_demands.file_ids` 存放附件 `id` 列表，模型通过 `files` 访问器取回 `Upload` 集合
|
|
|
|
|
|
说明：`public_way` 迁移中为 boolean，但注释为 1/2/3 三种模式（1直接公开/2私信后公开/3不公开）。当前以 0/1 存储，若需完整三态应在后续迁移中改为 tinyInteger。
|
|
|
|
|
|
#### 二、功能说明（`SupplyDemandController`）
|
|
|
|
|
|
- **列表 `index`**：按类型、状态、关键词、是否只看自己、有效期（有效/失效）筛选，分页排序；关联返回 `user` 基本信息。
|
|
|
- **详情 `detail`**：按 `id` 查询，返回 `user`，并自增 `view_count`；附带当前用户对该供需的已发私信次数。
|
|
|
- **保存 `save`**：新增或更新（新增时绑定当前用户并短信通知管理员），使用事务保存，支持 `file_ids`、`expire_time`、`contact_name` 等字段。
|
|
|
- **删除 `destroy`**：按 `id` 软删除。
|
|
|
- **发私信 `sendMessage`**：
|
|
|
- 若带 `supply_demand_id` 则自增浏览量；
|
|
|
- 无会话则创建会话；
|
|
|
- 限流：每天发送条数不超过配置 `message_limit`；
|
|
|
- 反骚扰：自己连续发送后需等待对方回复；
|
|
|
- 保存消息并更新会话最后内容与时间。
|
|
|
- **消息列表 `messageList`**：按 `to_user_id` 定位当前和对方的会话，分页返回消息（含双方用户信息）。
|
|
|
- **会话列表 `dialogues`**：返回与当前用户相关的会话（发起或接收），含双方用户与关联供需。
|
|
|
- **收藏相关**：
|
|
|
- `keepIndex`：我的收藏列表；
|
|
|
- `keepSupplyDemand`：收藏，去重创建；
|
|
|
- `unKeepSupplyDemand`：取消收藏。
|
|
|
|
|
|
#### 三、核心业务要点
|
|
|
|
|
|
- 审核机制：多状态闭环（待审/通过/拒绝/退回/隐藏）。
|
|
|
- 私信策略：限流 + 反骚扰（需对方回复后再发）。
|
|
|
- 有效期：支持有效/失效筛选。
|
|
|
- 公开模式：当前存储为布尔（0/1），业务含义为三态，后续建议迁移调整。
|
|
|
- 数据统计：浏览数 `view_count`、联系数 `contact_count`（可按消息交互推导）。
|
|
|
- 附件：`file_ids` JSON + `files` 访问器联表读取。
|
|
|
|
|
|
#### 四、测试数据生成目标
|
|
|
|
|
|
以 `supply_demands` 为起点，为每条主记录自动生成：
|
|
|
- 合理的 `uploads` 附件（0~3 个），`file_ids` 同步写入；
|
|
|
- 真实的会话 `dialogues`（0~2 个），双方用户随机；
|
|
|
- 合法的消息序列 `messages`（1~5 条），严格交替往来确保不违反“需对方回复”约束；
|
|
|
- 合理的收藏 `supply_demand_keeps`（0~5 条，去重）；
|
|
|
- 统计字段：`view_count` ≥ 消息条数，`contact_count` 依据消息往来推导。
|
|
|
|
|
|
#### 五、两种生成方式对比
|
|
|
|
|
|
- **方式A：数据库填充（Seeder）**
|
|
|
- 优点：
|
|
|
- 一次性执行、可集成到 CI 或初始化流程；
|
|
|
- 可与 `DatabaseSeeder` 串联；
|
|
|
- 便于多环境批量重置数据。
|
|
|
- 缺点：
|
|
|
- 运行参数（数量、用户规模）固定或需改代码；
|
|
|
- 无交互，临时性需求需改代码或 env。
|
|
|
|
|
|
- **方式B：Artisan 命令（Console Command）**
|
|
|
- 优点：
|
|
|
- 支持运行参数（如 `--count`、`--users`），灵活生成规模；
|
|
|
- 可多次按需执行，便于演示或局部补数；
|
|
|
- 缺点：
|
|
|
- 需要单独维护命令逻辑；
|
|
|
- 不会被自动纳入 `db:seed` 的全局流程。
|
|
|
|
|
|
推荐：开发/演示期使用命令（B）灵活试验；集成测试或初始化环境使用 Seeder（A）。
|
|
|
|
|
|
|
