服务目录模板生成引擎与资源模型集成 - 第2节

2.1 Resource Model 的定义

Resource Model（资源模型）是模板生成引擎中用于抽象、封装和传递数据的一种结构化契约。它不关心数据从何处来（数据库、API、缓存或配置文件），只定义“模板需要什么数据”以及“这些数据以怎样的层级和类型呈现”。

在模板引擎上下文中，Resource Model 承担以下职责：

• 数据契约：明确模板可访问的字段名称、类型和嵌套结构。
• 数据适配：将后端业务模型（如 ORM 实体、DTO）转换为模板友好的扁平或树形结构。
• 数据隔离：防止模板直接操作业务逻辑层的数据源，降低耦合。

2.2 Resource Model 在 MVC 架构中的位置

在经典的 MVC（Model-View-Controller）架构中，Resource Model 位于 View 与 Controller 之间，充当“视图专属数据层”。它不属于传统的 Model（业务模型），而是由 Controller 或 Service 层根据模板需求动态组装而成。

下图展示了 Resource Model 在 MVC 请求处理流程中的具体位置：

流程说明：

1. 客户端请求到达 Controller，Controller 调用 Service / Model 获取业务数据。
2. Controller 将业务数据组装为 Resource Model，只保留模板需要的字段。
3. Resource Model 被传递给 模板引擎，引擎根据模板文件进行渲染。
4. 最终生成 渲染输出（HTML、JSON、XML 等）返回给客户端。

2.3 Resource Model 与数据模型的区别

很多开发者容易将 Resource Model 与数据模型（Data Model）混为一谈。两者在职责、生命周期、设计目标和变更频率上有本质区别。下表从多个维度进行对比：

对比维度	Resource Model	数据模型（Data Model）
核心职责	为模板提供数据契约	为业务逻辑和持久化提供数据抽象
设计目标	模板友好、扁平化、易遍历	业务完整、关联清晰、范式化
生命周期	请求级别，渲染完成后即销毁	应用级别，常驻内存或持久化存储
变更频率	随模板需求变化而频繁调整	随业务规则变化而调整，相对稳定
包含关系	可能聚合多个数据模型的子集	通常对应单一业务实体或聚合根
字段数量	只包含模板需要的字段（精简）	包含业务实体的全部字段（完整）
嵌套深度	通常 ≤ 2 层，避免模板逻辑复杂	可能 3 层以上，反映业务关联
序列化关注	关注模板语法兼容性	关注 ORM 映射与数据库类型

下面通过一个具体示例来加深理解。假设有一个博客系统，数据模型包含 User、Post、Comment 三个实体，它们之间存在复杂的关联关系。但在首页模板中，只需要展示“最近 10 篇文章的标题、作者名和发布日期”。

// 数据模型示例（业务层）
public class Post {
    private Long id;
    private String title;
    private String content;
    private Long authorId;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
    private Integer status; // 0:草稿, 1:已发布, 2:删除
    // ... 其他业务字段
}

// Resource Model 示例（模板层）
public class PostSummaryResource {
    private String title;        // 文章标题
    private String authorName;   // 作者姓名（从 User 表关联获取）
    private String publishDate;  // 格式化后的发布日期（yyyy-MM-dd）
    // 只包含模板需要的 3 个字段
}

下图直观展示了 Resource Model 与数据模型在结构上的差异：