介绍

oor 是一个 NodeJs 的 ORM 框架,仅支持 PostgreSqlElastic SearchMySql

Github | npm version

特性

  1. 启动快,性能强 🚀。
  2. 强类型 TypeScript,即是 Type,又是 Code,还是 Schema!
  3. 简单易用 API(看左边使用手册,3篇文档即全部内容,半小时看完永不再来)
  4. 独特魔法后缀📍节省时间与代码行数。
  5. 支持 Elastic Search, 提供与 SQL 完全一致的 API!
  6. 业务性支持:分页、查询列过滤,逻辑删除,日期标识等。
  7. Promise

缺点

本框架缺点很多,非玩笑,谨慎使用!

  1. 个人项目,目前维护中,后面后情况,不会很稳定。
  2. 仅支持 PostgreSqlElastic SearchMySql,没有其它支持计划。
  3. 不支持关联,一对多等特性,就是一个简单、纯粹的单表ORM 😏。
  4. 最终对象是一个简易对象(json),不包含任何方法。
  5. 查询 API 太过灵活,导致很难生成 openapi/swagger 之类的文档

作者说

看完特性缺点后,如果有顾虑,请省下宝贵时间,不要使用,不需要往下看了。

作者以前也用过不少 ORM 框架。各有优点,但都不够简单。

有人说 :生命宝贵,我用 Python!

我特别认同,感觉大部分的 ORM 功能虽然强大,但真正用到的不多,越累越重,越设计越复杂,性能浪费越多,文档也多至几十页,一天都看不完。

其实大部分人使用这部分框架的时候,大部分的 "高级特性" 都是没用上的。

而相反,很多业务上常用的特性,传统的 ORM 反而不支持!比如 字段过滤、逻辑删除、时间管理、全局条件等。

当然这些都是和业务相关,通过ORM基本包二次动手也是可以实现的,但个人有些存在即道理,有些事应该放给ORM做,给开发人员整一点认知负担。

个人认为 :ORM 只提供基础功能,性能要快,省下80%的重复劳动就行,剩下20%请开发人员自己动手

出于以上心态: 如果只做一个 高频API核心ORM,把核心的 CRUD 做好就行,数据库也只支持一两个,应该还在个人能力范围内。

于是,就出现了这个小工具 oor ,如果喜欢请给我个 Star! 谢谢。