在 Oinone（开源低代码 / 企业应用开发平台） 里，Action 和 Function 都是“可被调用的逻辑单元”，但它们的定位和使用场景不同。可以简单理解为：
- Function = 纯逻辑函数（偏后端能力）
- Action = 面向业务操作的动作（偏应用行为 / UI触发）
下面给你详细对比一下。
1️⃣ Function：函数（逻辑能力）
Function 更像是一个 可复用的服务方法。
特点
- 通常是 纯逻辑处理
- 不直接绑定 UI
- 可以被 Action / Service / 其他 Function 调用
- 用来封装 业务计算或工具逻辑
常见用途
比如：
- 价格计算
- 数据校验
- 数据转换
- 调用第三方 API
- 复杂业务规则
示例
@Function(openLevel = FunctionOpenEnum.API)
@Function.Advanced(type = FunctionTypeEnum.QUERY)
public TradeOrder computePrice(TradeOrder data) {
return data;
}用途：
订单金额计算逻辑然后可能被多个地方调用：
Action -> 调用 Function
Service -> 调用 Function
Workflow -> 调用 Function📌 核心：可复用业务逻辑
2️⃣ Action：动作（业务操作）
Action 是一个 业务动作，通常是 用户触发的行为。
特点
- 通常绑定 UI
- 可以在 按钮 / 菜单 / API / 工作流 中触发
- 通常操作 模型数据
- 可以调用 Function
常见用途
例如：
- 创建订单
- 提交审批
- 发布文章
- 批量删除
- 导入数据
示例
@Action
public void submitOrder(Order order){
order.setStatus("SUBMITTED");
}UI 可能是：
订单详情页
[提交订单] 按钮点击按钮 → 调用 Action。
📌 核心：业务行为入口
3️⃣ 核心区别总结
| 维度 | Action | Function |
|---|---|---|
| 定位 | 业务动作 | 逻辑函数 |
| 是否绑定 UI | 通常是 | 否 |
| 是否直接给用户操作 | 是 | 否 |
| 是否可复用 | 一般 | 很高 |
| 是否操作模型 | 常见 | 不一定 |
| 调用关系 | 可调用 Function | 不调用 Action |
4️⃣ 调用关系（典型架构）
通常推荐的结构：
UI按钮
↓
Action（业务入口）
↓
Function（业务逻辑）
↓
DAO / Repository例如：
提交订单按钮
↓
submitOrderAction
↓
checkInventoryFunction
calcPriceFunction
createOrderFunction这样：
- Action 只负责 流程
- Function 负责 逻辑
代码会更清晰。
5️⃣ 一句话理解
Action = 用户触发的业务操作
Function = 可复用的业务逻辑函数
💡 如果你在 Oinone 做模块开发，我可以再给你讲一个更实用的：
“什么时候写 Action，什么时候写 Function” 的最佳实践（很多人会写反）。
他们在权限上有什么区别
在 Oinone 里，Action 和 Function 在权限控制上的区别其实很明显：
Action 是有权限控制的业务入口，而 Function 通常没有独立权限控制。
可以从几个层面理解。
1️⃣ Action：有权限控制（面向用户）
Action 通常直接参与权限体系。
因为 Action 往往对应：
- 页面按钮
- 菜单操作
- API接口
- 工作流节点动作
所以平台会对 Action 做权限控制。
常见控制方式
Action 可以被：
- 角色权限控制
- 菜单权限控制
- 数据权限控制
- 按钮可见性控制
例如：
角色：销售
✔ 提交订单 Action
✔ 查看订单
✘ 删除订单 Action如果用户没有权限：
- 按钮不会显示
- 或调用 API 时被拒绝
📌 Action 是权限体系的主要控制点。
2️⃣ Function：通常没有独立权限
Function 只是逻辑方法，不直接暴露给用户。
它通常：
- 只能被 Action / Service / Workflow 调用
- 不直接作为 UI 操作入口
因此 Function 一般不做权限控制。
例如：
submitOrderAction
↓
calcPriceFunction
checkInventoryFunction
createOrderFunction权限只在：
submitOrderAction检查一次即可。
3️⃣ 为什么设计成这样
这是典型的 业务入口权限模型：
用户
↓
Action（权限控制）
↓
Function（内部逻辑）
↓
数据好处：
1️⃣ 权限集中
2️⃣ 避免重复校验
3️⃣ Function 可复用
否则：
10个 Action
调用同一个 Function每个 Function 再做权限判断会非常混乱。
4️⃣ 一个真实场景
删除订单
deleteOrderAction权限：
角色：管理员 ✔
角色：销售 ✘Action：
deleteOrderAction
↓
deleteOrderFunction如果销售没有权限：
- 按钮不显示
- API 不允许调用
但 deleteOrderFunction 仍然存在，只是不会被调用。
5️⃣ 特殊情况（高级开发）
有些团队会在 Function 内再做安全校验，例如：
- 防止被错误调用
- 防止内部接口滥用
例如：
checkPermissionFunction()但这属于 业务安全设计，不是 Oinone 的默认权限模型。
6️⃣ 一句话总结
| 对比 | Action | Function |
|---|---|---|
| 是否有权限控制 | ✅ 有 | ❌ 通常没有 |
| 是否直接暴露给用户 | ✅ 是 | ❌ 否 |
| 是否是权限入口 | ✅ 是 | ❌ 不是 |
| 是否可被 UI 按钮触发 | ✅ 可以 | ❌ 不可以 |
核心理解：
权限控制在 Action 层，Function 是内部逻辑。
如果你在 Oinone 做企业系统开发，还有一个非常关键的点很多人会搞错：
Action 的权限 ≠ 数据权限（Data Permission）
Oinone社区 作者：nation原创文章，如若转载，请注明出处：https://doc.oinone.top/frontend/25520.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
