前言
这是一篇个人跟随抖音账号 哲玄前端 学习 《大前端全栈实践》 后的学习总结。
elpis 前端全栈框架凭借领域模型架构这一核心设计，展现出强大的实用价值。它能够有效沉淀绝大多数 CRUD这类重复性工作，极大减少了开发者在基础操作上的时间投入。与此同时，框架并非局限于固定模式，还提供了灵活的拓展能力，让开发者可以根据实际业务需求进行个性化调整与功能延伸，从而在提升开发效率的同时，有力保障了项目质量，实现了提效与保质的双重目标。
1 框架设计
如图所示，该框架分为三层，分别是展示层 ，BFF层 和数据层。
展示层巧妙地融合了SSR和CSR两种模式，在配置多个单页面入口的基础上，赋予每个单页面通过前端路由跳转子页面的能力。
BFF 层细分为接入层、业务层和服务层，接入层主要负责路由分发，通过分析页面请求来判断是进行渲染操作还是调用 BFF 接口；业务层聚焦于前端页面所需的各类业务处理，为页面功能实现提供业务逻辑支撑；服务层则主要承担获取数据的处理工作，保障数据的有效获取与传递。
数据层包括了数据库，日志，后端服务接口以及其他各类数据来源。
1.1 展示层
elpis的展示层是 SSR 架构 ，基于 MVVM 框架 构建，整合 UI 组件库 与资源的管理系统。应用通过服务端渲染生成单页面入口 ，各业务模块以单页面应用 (SPA) 形式组织，通过前端路由系统实现子页面间的无缝切换，同时保持服务端渲染的性能优势
elpis会对高频使用的前端页面进行抽象建模，形成标准化模板库 ，这些模板包含完整的交互逻辑、状态管理与样式规范，通过持续迭代形成可复用的框架资产，后续开发利用模板库即可快速配置生成模板页 ，从而减少 80% 以上的重复开发工作。同时，elpis也具备渐进式定制能力：
- 配置级扩展：通过参数覆盖实现基础定制
- 组件级扩展：替换局部组件实现差异化
- 页面级扩展：可直接跳转到定制化页面
1.2 BFF层
elpis 的 BFF 层采用洋葱模型构建请求处理管道，通过中间件机制实现请求 - 响应生命周期的分层治理。前端请求经路由分发后，依次经过前置中间件（参数验证、错误捕获）、业务逻辑处理、后置中间件（数据转换、缓存注入），最终输出适配前端的响应格式。
2 服务端内核引擎
elpis 的服务端框架是基于 Koa2 实现的
elpis 服务端框架的核心模块构成及功能如下：
- elpis-core ：作为后端服务的启动入口，其核心组件解析器（loader）承担着将静态文件体系转换为运行时实体的关键职责。例如，解析 middleware.js 后，可在运行时通过 app.middleware 直接访问对应的中间件。
- router-schema：定义 API 接口的 Schema 规范，用于统一接口配置标准。
- router：负责页面请求的路由配置，管控请求的分发路径。
- controller：作为业务处理层，专注于处理具体业务逻辑。
- service：作为服务处理层，封装通用服务逻辑，为业务层提供支撑。
- config：存储项目配置信息的模块，包含版本、名称等基础配置项。
- extend：用于扩展项目功能的模块，可集成日志、数据库等附加能力。
2.1 elpis-core loader
为使解析器能够识别并实例化各类业务组件，elpis 制定了严格的目录规范与文件契约。例如，所有开发的中间件需统一放置于项目的 app/middleware 目录中，各文件目录的具体结构如下（图示）。
2.2 页面渲染
elpis 使用了 koa-nunjucks-2 实现SSR渲染
elpis 会将前缀为 /view 的请求识别为页面渲染请求 。例如，当请求路由为 /view/project/list?key=1 时，Elpis 在路由分发阶段会自动导向 viewController 中的 renderPage 函数；因为elpis的路由配置是 /view/:page/* ,所以 Koa-Router 会解析 URL 的时候将 { page: project-list } 提取到 ctx.params 对象，同时也把 { key: 1 } 提取到 ctx.query对象，随后在 renderPage 内部通过调用 koa-nunjucks-2 中间件提供的 render 函数，找到前端工程化构建的 entry.project-list.tpl 文件，输出相应页面。
2.3 API请求
elpis 的参数拦截是基于 ajv 和 json-schema 实现的
elpis 会将前缀为 /api 的请求识别为 API 请求，这类请求经路由分发后会导向对应的 controller。正如 1.2 章节所述，Elpis 采用洋葱圈模型，因此请求在进入 controller 前后会经过中间件的处理：例如进入前会经过 api-params-verify 中间件，该中间件基于 json-schema 和 ajv 实现参数校验；而对于业务处理中抛出的错误，则由 error-handle 中间件拦截并统一处理。
3 前端工程化构建
elpis 的前端工程化构建是基于 webpack5 实现的
前文 2.2 章节已提及页面渲染需用到 entry.project-list.tpl 文件，那这个文件是如何生成呢？本章将重点说明 elpis 如何通过前端工程化构建生成页面所需文件。
如上图所示，解析引擎基于 webpack5 实现。由于 elpis 是多页面项目，其会将 pages 目录下包含entry.xxx.js文件的文件夹识别为单页面，并以该 entry.xxx.js 文件作为对应页面的入口，对其进行编译、分包及压缩优化，最终生成 entry.xxx.tpl 及 js、css 等文件，输出至 dist 目录中。
3.1 开发环境
开发服务器是基于 Express 实现的
在开发环境中，若每次修改代码都需手动执行构建命令，等待文件落地后才能查看效果，会显著降低开发效率。为此，elpis 在开发构建环节提供了热更新功能。
如上图所示，elpis 基于 Express 实现了开发环境专用的 dev-server （开发服务器），其核心由监听器 与通知器两大组件构成：
- 监听器基于
webpack-dev-middleware实现，核心职责是实时监听业务文件的变更； - 通知器由
webpack-hot-middleware实现，主要负责与浏览器端产物中包含的 HMR 客户端（负责建立双向通信的代码片段）建立连接，当有新文件生成时，它会主动告知 HMR 客户端有更新，同时接收客户端的接收状态反馈。
当监听器检测到业务文件发生变化时，会触发重新编译、分包及优化流程。其中，生成的 tpl 文件 会直接输出到 dist 目录，而 tpl 中引用的 js、css 等资源文件则会被注入 dev-server 的内存中。随后，通知器会立即通知 HMR 客户端更新信息，促使浏览器重新拉取新资源，最终实现开发过程中 "保存即见最新效果" 的流畅体验。
4 领域模型架构
elpis 支持自定义模型结构与模型解析器的开发，并可通过模板引擎生成相应系统，目前已支持中后台管理系统的 dashboard 模板。
4.1 架构设计
如上图所示，通过配置 DSL 模板页即可生成对应的系统页面。其中，dashboard 模板页包含 header-container 组件，用于配置头部菜单；每个菜单可配置四种页面类型：sider-view 、schema-view 、iframe-view 和 custom-view。
- 模板解析器：将配置生成页面所需要的数据结构；
- sider-view：侧边栏页面，支持通过配置文件关联三种侧边菜单页面，即 schema-view 、iframe-view 和 custom-view；
- schema-view：框架沉淀的标准化表格页面，具体细节将在后续章节详述；
- iframe-view：用于嵌入 iframe 的页面，可在配置文件中指定需嵌入的 URL；
- custom-view：定制化页面，支持在配置文件中定义具体路由路径，通过该路由可直接跳转至对应页面。
4.2 模板配置
如上图所示，A 电商系统与 B 电商系统存在大量相同配置。为此，elpis 在配置中引入了面向对象思想：在配置具体项目（project）前，会先定义一个领域模型（model），项目则通过继承该模型的配置，无需重复设置与模型一致的内容，仅需重新配置需要修改或新增的配置项即可。
4.2 dashboard 模板页
如上图所示，dashboard 由 header-container 和页面区两部分构成：
- header-container：包含头部菜单与 info-content（例如登录人员、项目等信息展示区）；
- 页面区：若当前页面类型非 sider-view，则直接显示对应内容；若为 sider-view，则先展示侧边菜单栏，点击菜单后再显示对应内容。
4.3 schema-view 设计
schema-view 是 elpis 在 dashboard 模板中重点沉淀的标准化页面，核心为表格形态，不仅集成了数据增删改查的基础能力，还支持按需拓展定制化功能。
如上图所示，schema-view 主要包含三大功能模块：
- schema-search-bar：表格的查询区域，支持配置 input、select 等多种类型的查询控件；
- schema-table：表格展示区域，可配置列字段、操作按钮等元素；
- schema-form：表格操作关联的表单区域，用于处理新增、编辑等数据操作。
4.4 schema-view 配置
为实现表单页通过单一配置即可完成开发，elpis 的 schema-view 配置设计得十分具体，主要包含以下核心部分：
go
schemaConfig:{
api:'',// 数据源API（遵循RESTFUL规范）（GET获取，POST新增，PUT修改，DELETE删除）
schema:{ // 板块数据结构
type:'object',
properties:{
key:{
...schema,// 标准的shema配置
type:'',// 字段类型
label:'',// 字段的中文名
// 字段在 table中的相关配置
tableOptions:{},
// 字段在search-bar中的相关配置
searchOptions:{}
},
...
},
required: [], // 标记哪些字段是必填项
},
// table相关配置
tableConfig:{
headerButtons:[],// table头部按钮
rowButtons:[],// table行按钮
},
// search-bar相关配置
searchConfig:{},
// 动态组件相关配置
componentConfig:{}
},- api：若配置为
'/project'，则该页面的接口会自动映射为：列表查询使用GET('/project/list')，新增使用POST('/project')，删除使用DELETE('/project')，修改使用PUT('/project')，详情查询使用GET('/project')； - schema：格式遵循 json-schema 规范，每个 key 对应一个字段的具体配置；
- config 与 options：config 用于定义模块在页面中的整体表现（如 tableConfig 可配置头部按钮、行内按钮等）；options 则用于设置字段在模块中的具体表现（如 tableOptions 可指定字段是否在表格中显示、显示时保留的小数位数等）。
4.5 动态组件
在 4.4 章节的配置中提到，schema 配置包含动态组件配置。实际上，elpis 的动态组件功能正是为了沉淀更多通用功能（如弹窗、表单、抽屉等）而设计的。例如，点击新增按钮时，会弹出基于 4.3 章节所述schema-form实现的新增表单弹窗；再如点击详情按钮时，可触发抽屉组件弹出，用于展示单条数据的具体内容。
4.6 DSL总结
如下图所示，elpis 目前已支持通过 "先配置领域模型、再配置项目" 的流程，经模板解析生成完整的 dashboard 系统。其中绿色背景区域为可根据业务需求定制的内容，既沉淀了大量重复性工作，又支持定制化内容的灵活拓展。随着模板库（如商城、APP 等场景模板）的持续迭代，elpis 最终将实现通过单一配置生成多领域、多模板框架的目标。
5 封装 npm 包
由于 elpis 的设计初衷是打造全栈框架，其最终使用方式为：业务项目通过引入 npm 包开展开发。如下图所示，当业务项目引入 elpis 后，需开发绿色背景框所标识的内容控件扩展（如 search-bar、form、schema-view 等） 和 配置模板。
5.1 启动方式
由于 elpis 的最终形态是一个 npm 包，需向业务项目提供启动与构建能力，因此 elpis 对外暴露了两个核心方法：后端启动的serverStart与前端构建的frontendBuild。
serverStart：接收option参数，可传入项目名称等相关配置；frontendBuild：支持传入环境变量，用于构建对应环境的前端项目。
5.2 业务项目开发方式
为使 elpis 能识别业务项目开发的定制控件与配置模板，其规定了业务项目中特定目录与内容的对应关系：
如上图所示，服务 loader 部分与 2.1 章节一致：elpis-core 会将业务项目对应路径的文件加载为运行时所需的实体对象。 前端构建部分的目录规范如下：
- 自定义扩展页需在
app/pages/目录下创建页面入口文件； - 其他组件相关的扩展开发完成后，只需在对应目录的配置文件中添加组件配置，即可被 elpis 前端构建流程一并处理；
- 模板配置则统一放置于
model/目录下。
总结
以上就是本文关于 elpis 的全部内容，本文侧重介绍 elpis 的设计思路。若你对 elpis 源码感兴趣，可在 npm 搜索 "elpis"，会看到多个相关包 ------ 这些均是学习《大前端全栈实践》课程后实现的 npm 包。
若对课程感兴趣，可前往抖音 "哲玄前端" 购买课程，私信商家时输入 "Befool"，即可开启你的探索之旅。