DTO 定义 UI · Handler 聚合业务场景
PasteApeart 是 PasteForm（All in Dto） 的进阶版。
通过 DTO 元数据驱动管理端 UI，并以业务场景（Business Scenario）聚合业务逻辑，
实现管理端 0 代码 + 业务逻辑一次编写、多宿主复用。
双支柱 · UI + 业务双收敛
PasteApeart 的核心是两条平行的收敛原则：All in Dto 收敛 UI 呈现，All in Handler
收敛业务规则，
将管理后台开发从“重复适配”提升到“范式约束”。
All in Dto
UI 由 DTO 元数据驱动
将表格、搜索区、表单、新增/编辑/详情页的控件类型、布局、交互规则，都定义在 DTO 的特性（Attributes）与注释中。框架通过反射读取
VoloModelInfo 元数据，由通用前端统一渲染。
- DTO 改动即 UI 改动，前后端一次对齐
- 管理端近乎 0 代码，页面骨架 index.html / view.html /detail.html 通用复用
- 元数据驱动（VoloModelInfo），思想可跨语言平移
- 统一 UI 范式，杜绝管理端风格割裂
All in Handler
业务按场景聚合到 Handler
将业务逻辑按业务场景（Business Scenario）聚合到 Handler
层，而不是按单表散落。Application 只做单表 CRUD 协调（大部分场景 0 代码），Host
只做跨表视图聚合。
- 业务收敛中心：一个业务场景的所有规则只写一次
- 多宿主复用：一次编写，可被 6 种宿主反复调用
- 职责清晰：Host → Application → Handler 严格单向引用（硬约束）
- 杜绝业务扩散：强制业务收敛，架构更清晰、更易维护
从 PasteForm 到 PasteApeart
PasteApeart 是 PasteForm 的进阶版，并非推翻，而是进一步把“业务逻辑该放在哪”这个问题收敛到了
Handler 层。
All in Dto
专注解决“管理端重复开发、前后端字段不一致”的问题。通过 DTO 元数据驱动 UI，实现管理端自动化。
All in Dto + All in Handler
在 All in Dto 的基础上，进一步解决“业务逻辑复用、职责边界混乱”的问题。将业务按场景聚合到 Handler，实现业务规则的多宿主复用。
痛点：重复的不是业务，是适配与组织方式
管理后台不仅面临字段同步的重复劳动，更面临复杂业务逻辑该写在哪、如何复用这个长期困扰团队的架构问题。
管理端重复开发
数十张表的 CRUD，结构雷同却要反复适配，字段增删需要多处同步。
前后端字段脱节
DTO、API、前端表单难以保持一致，维护成本随表数量线性增长。
业务逻辑复用困难
同一段跨表业务规则，常被复制到 Controller、Job、MQ、定时任务等不同入口，导致重复与不一致。
代码放置混乱，难以收敛
复杂业务堆砌在 AppService，职责不清，项目久了容易腐化，架构约束不够明确。
解决方案：DTO 定义 UI · Handler 聚合业务场景
PasteApeart 用两条收敛原则解决这两个层面的重复：UI 呈现收敛到 DTO 元数据，业务规则收敛到 Handler 场景。
传统方式
- 手写列表页、表单页、详情页 → 字段多处同步
- 业务逻辑按入口/单表散落（Controller、Job、MQ 重复实现）
- 跨表复杂逻辑难以复用，容易出现逻辑不一致
- 缺乏明确的架构硬约束，职责边界模糊
PasteApeart（All in Dto + All in Handler）
- DTO + 特性定义 UI → 元数据自动渲染，改动一处即全局生效
- Handler 按业务场景聚合 → 业务规则一次编写，到处复用
- 多宿主复用（HTTP/MQ/Timer/Job/Event/Background）→ 逻辑永远一致
- Host → Application → Handler 单向引用硬约束 → 职责清晰、可维护
架构设计 · Handler 是业务收敛中心
PasteApeart 将职责严格划分为 Host · Application · Handler 三层，
强制 Host → Application → Handler 单向引用（编译器级硬约束），将业务逻辑彻底收敛到 Handler 层。
DefaultAppService 可实现 0 代码 CRUD6 种宿主复用 · 一次编写，到处复用
在 PasteApeart 中，业务场景被聚合到 Handler。
同一个 Handler 方法，不需要复制粘贴，就能被以下 6 种宿主调用，实现业务逻辑 100% 复用。
一个业务场景（Scenario）只在 Handler 写一次，所有入口共用同一套业务规则，避免逻辑重复和不一致。
核心特性
PasteApeart 将 UI 自动化（All in Dto）与业务场景聚合（All in Handler）有机结合，
在减少重复劳动的同时，强化了架构的可维护性与业务复用性。
All in Handler · 业务场景聚合
按业务场景组织 Handler，业务规则一次编写即可被 HTTP、MQ、Timer、Job、Event、Background 等 6 种宿主复用，实现业务逻辑 100% 复用。
All in Dto · 元数据驱动 UI
DTO + 特性定义 UI，框架输出 VoloModelInfo 元数据，由通用前端统一渲染表格、搜索、表单、详情，实现管理端近乎 0
代码。
IEventModel · 事件模型
内置延迟执行（ExpireSecond）、绝对时间（ExpireTime）、自动幂等（MutexKey），配合
EventActionHandler 统一调度，优雅解决异步、延迟、幂等三大痛点。
三层架构 · 硬约束
Host → Application → Handler 严格单向引用（编译器级物理约束）。职责边界清晰，强制业务收敛，有效防止架构腐化。
config.json · 批量规则
支持动态字段注入、特性批量预设（attribute.all），减少 DTO 重复标注，让全局规则集中可维护。
Liquid 模板 · 可定制生成
通过 *.html.liquid 自定义 DTO、Service 等代码生成模板，配合 PasteBuilder 满足团队不同的代码风格偏好。
特性系统 · 用 DTO 特性控制 UI 呈现
PasteApeart 的特性系统（Attributes）源自 PasteApeart.Helper，
一行特性即可决定字段的控件类型、校验、布局、交互、显隐等行为，真正做到“All in Dto”。
基础信息（Model Meta）
布局、分组与自定义
选择控件
关联数据（外表、嵌套对象）
上传控件
富文本 / 内容编辑
日期时间
查询、联动
操作按钮、菜单
校验、限制
显示控制
数据转换
未找到匹配的特性，请尝试其他关键词
完整特性说明与参数详情见： PasteApeart.Helper 特性文档（md.md）
事件模型（IEventModel）· 与 Handler 场景深度结合
基于 IEventModel，PasteApeart 将延迟执行、绝对时间、自动幂等内置到事件体系中。
配合 Handler 的业务场景聚合，使得异步任务、延时处理同样能做到一次定义、多宿主复用。
延迟执行
通过 ExpireSecond 配置，轻松实现“X 秒后执行”，适用于延时关闭、超时处理等场景。
绝对时间
通过 ExpireTime 配置，支持指定时间点执行（如每天凌晨 3 点），满足定时/计划任务场景。
自动幂等
通过 MutexKey 配置，由 EventActionHandler 统一基于 Redis/DB 做排重，确保事件永远只执行一次。
多宿主复用
事件可与 Handler 场景配合使用，在不同宿主入口触发同一业务处理逻辑，只需实现一次。
AbsBaseModel 并实现 IEventModelMutexKey、ExpireSecond / ExpireTimeEventActionHandler 统一调度、排重与执行public class OrderCreatedEvent : AbsBaseModel, IEventModel
{
public string OrderId { get; set; } = string.Empty;
public string UserId { get; set; } = string.Empty;
// 延迟 30 分钟执行（ExpireSecond：秒）
public int ExpireSecond { get; set; } = 1800;
// 绝对执行时间（可选，用于指定时间点执行）
public DateTime? ExpireTime { get; set; }
// 自动幂等键（按业务唯一键生成，确保只执行一次）
public string MutexKey => $"order:created:expire:{OrderId}";
}工具链 · 配套生态，开箱即用
PasteApeart 不止是框架，更是一套围绕“All in Dto + All in Handler”的生产力工具链。
PasteBuilder · 代码生成器
CodeFirst，一键生成 DTO（Add/Update/List/InputQuery）、AppService、EF 配置等骨架代码。配合 Liquid 模板与
config.json 可深度定制生成风格。
- 统一团队代码规范，减少重复骨架代码
- 支持 Liquid 模板（
*.html.liquid）自定义 - 配合
config.json批量预设特性，减少标注
PasteSpider · 智能部署
智能差异发布、热更新、无感部署、多环境隔离、平滑升级，让发布流程更简单、更安全、更可控。
- 只上传变更文件，提升发布效率
- 热更新无感生效，降低服务中断风险
- 开发/测试/生产环境一键切换
如何工作 · 3 步极速上手
将 All in Dto + All in Handler 的理念，落到实践只需简单 3 步。
定义 DTO 并标注特性
编写 Add/List/Update/InputQuery DTO，在字段上添加 Paste* 特性（Attributes），描述控件类型、校验、布局、交互等 UI 规则。
按业务场景编写 Handler
将跨表复杂业务按业务场景聚合到 Handler 层，单表 CRUD 则继承 DefaultAppService
（大部分 0 代码）。框架自动暴露 VoloModelInfo 元数据。
自动渲染管理端 + 多宿主复用
通用页面 index.html / view.html / detail.html 根据元数据自动渲染管理端。Handler 业务场景可按需被
6 种宿主复用。
适用场景
清晰的边界，帮你判断是否适合你的项目。
推荐使用
- 后台管理系统、运营后台、CMS、CRM、ERP 等内部管理平台
- CRUD 密集 + 业务复杂（表较多、字段频繁变化、且存在大量跨表业务场景）
- 需要统一管理端 UI 与统一业务架构约束的团队
- 希望业务逻辑能跨 HTTP/MQ/Timer/Job/Event/Background 多入口复用的项目
- 基于 .NET 6.0+ 的项目，想进一步提升管理端效率与架构规范
暂不推荐
- 高度定制的 C 端复杂交互（复杂动画、自由度极高的图形编辑等）
- 纯前端驱动、对 UI 自由度要求极高的可视化大屏
- 业务逻辑极简单且一次性、不需要管理后台与多入口复用的场景
All in Dto + All in Handler
DTO 定义 UI，Handler 聚合业务场景。
把管理端还给框架，把业务收敛到 Handler，让你的代码更清晰、更可复用、更易维护。