后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载EntityRepository 是 MikroORM 在 EntityManager 之上提供的薄封装层它天然携带实体类型信息免去每次find/findOne都要重复传入实体类的负担同时是扩展查询逻辑如自定义方法、批量查询、领域逻辑的标准切入点。本文基于 MikroORM 5.9 官方文档与仓库源码系统讲解默认仓储的用法、自定义仓储的注册与类型推断、全局基类仓储的搭建以及 v6 中从仓储上移除持久化方法的缘由与替代方案帮助你在实际项目中正确选用仓储层。EntityRepository携带实体类型的 EntityManager 代理官方文档将 EntityRepository 定义为EntityManager 之上的一层薄封装thin layers on top ofEntityManager默认实现只是把调用转发给底层的 EntityManager 实例。从源码看packages/core/src/entity/EntityRepository.ts 的构造函数只接收两个成员export class EntityRepositoryEntity extends object { constructor( protected readonly em: EntityManager, protected readonly entityName: EntityNameEntity, ) {} // ... }这意味着每个仓储实例都绑定了一个具体的实体类型entityName因此调用查询方法时不再需要像em.find(Book, ...)那样重复传入实体类const booksRepository em.getRepository(Book); const books await booksRepository.find({ author: ... }, { populate: [author], limit: 1, offset: 2, orderBy: { title: QueryOrder.DESC }, }); console.log(books); // Book[]上面的调用与em.find(Book, { author: ... }, { ... })完全等价——从 EntityRepository.find 的实现可以看到它只是把this.entityName连同where与options一并转发给this.getEntityManager().find(...)。populate、limit、offset、orderBy等选项与 EntityManager 层面的语义完全一致populate用于批量加载关联orderBy配合QueryOrder枚举控制排序方向。仓储的获取与缓存em.getRepository()在 EntityManager.ts 中的实现要点如下getRepositoryEntity extends object, Repository extends EntityRepositoryEntity EntityRepositoryEntity( entityName: EntityNameEntity, ): GetRepositoryEntity, Repository { const meta this.metadata.get(entityName); if (!this.#repositoryMap.has(meta)) { const RepositoryClass this.config.getRepositoryClass(meta.repository) as ConstructorEntityRepositoryany; this.#repositoryMap.set(meta, new RepositoryClass(this, entityName)); } return this.#repositoryMap.get(meta) as GetRepositoryEntity, Repository; }仓储实例按元数据缓存于#repositoryMap同一个实体多次调用getRepository()返回的是同一个实例实例化时通过Configuration.getRepositoryClass(meta.repository)决定使用哪个仓储类其解析顺序在 Configuration.ts 中清晰可见实体定义的repository回调优先 → 全局配置的entityRepository次之 → 最后回退到平台默认仓储类this.#platform.getRepositoryClass()。这正是后面实体级自定义仓储与全局基类仓储两条注册路径的底层依据。关于刷新仓储的澄清文档特别强调不存在刷新仓储flushing repository这一概念。仓储上并没有独立的持久化上下文flush始终是针对整个 Unit of Work 的。也就是说无论你在多少个仓储上做了修改一次em.flush()会把当前上下文identity map中所有待持久化的变更一次性写入数据库而不是只刷新某一个实体。这一点在后续移除的方法一节中体现得更彻底。自定义仓储扩展查询与领域逻辑创建并注册自定义仓储自定义仓储只需继承EntityRepositoryT。需要注意要访问驱动特有方法如createQueryBuilder()必须使用从驱动包导出的EntityRepository类型而不是mikro-orm/core中的通用类型import { EntityRepository } from mikro-orm/mysql; // 或其他驱动包postgresql、mongo 等 export class CustomAuthorRepository extends EntityRepositoryAuthor { // 自定义方法... public findAndUpdate(...) { // ... } }注册方式是在实体定义中传入customRepository回调。文档特别提示v5 起Repository()装饰器已被移除统一改用Entity({ customRepository: () MyRepository })Entity({ customRepository: () CustomAuthorRepository }) export class Author { // ... }回调形式() CustomAuthorRepository是刻意设计的当仓储内部引用了实体类时直接传类引用会产生循环依赖回调可延迟求值从而规避该问题。注册完成后即可通过em.getRepository()拿到自定义仓储const repo em.getRepository(Author); // 运行时是 CustomAuthorRepository 实例从Configuration.getRepositoryClass的解析顺序可见实体上指定了repository回调时它会覆盖全局entityRepository配置与平台默认类这正是实体级定制生效的原理。让类型系统认识自定义仓储EntityRepositoryType运行时注册解决了用哪个类但em.getRepository()的静态返回类型默认仍是通用的EntityRepositoryT。要让 TypeScript 推断出具体的自定义仓储类型需要在实体上声明EntityRepositoryType符号import { EntityRepositoryType } from mikro-orm/core; Entity({ customRepository: () AuthorRepository }) export class Author { [EntityRepositoryType]?: AuthorRepository; } const repo em.getRepository(Author); // repo 的类型是 AuthorRepositoryEntityRepositoryType在 typings.ts 中定义/** Symbol used to declare a custom repository type on an entity class (e.g., [EntityRepositoryType]?: BookRepository). */ export const EntityRepositoryType Symbol(EntityRepositoryType);而 typings.ts 中的GetRepository类型工具会优先读取实体上声明的该符号类型否则回退到通用EntityRepositorytype GetRepository... Entity[typeof EntityRepositoryType] extends EntityRepositoryany | undefined ? NonNullableEntity[typeof EntityRepositoryType] : ...仓库测试 tests/features/decorators/legacy/decorators.test.ts 给出了真实组合范例——自定义仓储在内部直接使用this.em.persist与this.em.flush实体通过[EntityRepositoryType]?: BookRepository声明类型这正是文档所述模式在测试中的落地class BookRepository extends EntityRepositoryBook { save(book: Book): void { this.em.persist(book); } flush(): Promisevoid { return this.em.flush(); } } export class Book { // ... [EntityRepositoryType]?: BookRepository; }全局自定义基类仓储若希望所有未显式指定customRepository的实体都默认使用某个自定义基类可通过MikroORM.init的entityRepository配置全局注册MikroORM.init({ entityRepository: CustomBaseRepository, // ... });该配置项的类型声明见 Configuration.ts在getRepositoryClass中位于实体级repository回调之后的第二优先级。注意这一配置同样只影响运行时实例化不影响em.getRepository()的静态类型推断——若需要全局类型推断应在公共基类实体上声明EntityRepositoryType见下文。深度进阶类型推断的边界与基类实体上的符号声明全局配置不参与类型推断文档明确指出全局entityRepository配置只决定运行时实例化哪个类TypeScript 无法从中推断仓储类型。要让em.getRepository()返回正确类型必须二选一在每个实体定义上显式指定repository即自定义仓储注册路径在公共基类实体上声明EntityRepositoryType让所有继承者默认继承该类型。在基类实体上声明EntityRepositoryType当项目使用公共基类实体例如统一管理主键的BaseEntity时可以在基类上一次性声明符号类型import { EntityRepositoryType, PrimaryKey } from mikro-orm/core; export abstract class BaseEntity { [EntityRepositoryType]?: BaseRepositorythis; PrimaryKey() id!: number; }此后em.getRepository(AnyEntityExtendingBaseEntity)会直接返回BaseRepositoryT无需在每个实体上重复声明某个实体若需要专属仓储仍可在其定义中覆盖customRepository并声明更具体的符号类型。通用基类仓储的写法当希望所有仓储共享自定义方法时可创建泛型基类仓储注意泛型参数的正确传递import { EntityRepository, EntityManager } from mikro-orm/mysql; // 或其他驱动包 export class BaseRepositoryEntity extends object extends EntityRepositoryEntity { // 所有自定义方法复用同一个 Entity 类型参数 // 父类提供的 this.em 与 this.entityName 可直接使用。 async exists(where: FilterQueryEntity): Promiseboolean { const count await this.count(where); return count 0; } async findOrCreate(where: FilterQueryEntity, data: RequiredEntityDataEntity): PromiseEntity { let entity await this.findOne(where); if (!entity) { entity this.create(data); await this.em.flush(); } return entity; } }全局注册MikroORM.init({ entityRepository: BaseRepository, });在此基础上实体专属仓储可以继承该基类并叠加专属方法export class AuthorRepository extends BaseRepositoryAuthor { async findActive(): PromiseAuthor[] { return this.find({ active: true }); } }通过实体定义的repository注册后em.getRepository(Author)返回的AuthorRepository同时具备基类的通用方法与实体专属方法未指定专属仓储的其他实体则继续使用BaseRepository。v6 起从仓储中移除的持久化方法文档后半部分聚焦一个重要的 API 变更自 v6 起以下方法不再存在于EntityRepository实例上persistpersistAndFlushremoveremoveAndFlushflush移除理由是这些方法会带来作用域上下文的错觉——开发者可能以为repo.persist(...)只作用于该仓储对应的实体类型而实际上它们只是底层 EntityManager 同名方法的捷径持久化的始终是整个 Unit of Work。因此文档建议涉及实体持久化的操作直接使用 EntityManager仓储应定位为自定义逻辑如封装 QueryBuilder 用法的扩展点。替代方案一通过getEntityManager()需要持久化时可用仓储的getEntityManager()方法取到底层 EntityManager 再操作。该方法的实现见 EntityRepository.tsgetEntityManager(): EntityManager { return this.em; }替代方案二自定义基类仓储恢复旧方法若团队确实希望保留仓储级持久化方法可以自定义基类仓储并全局启用import { EntityManager, EntityRepository } from mikro-orm/mysql; export class ExtendedEntityRepositoryT extends object extends EntityRepositoryT { persist(entity: object | object[]): EntityManager { return this.em.persist(entity); } async persistAndFlush(entity: object | object[]): Promisevoid { this.em.persist(entity); await this.em.flush(); } remove(entity: object): EntityManager { return this.em.remove(entity); } async removeAndFlush(entity: object): Promisevoid { this.em.remove(entity); await this.em.flush(); } async flush(): Promisevoid { return this.em.flush(); } }MikroORM.init({ entityRepository: ExtendedEntityRepository, });注意这些方法内部依然委托给this.em即作用域仍是整个 Unit of Work。若需要同时恢复类型推断可结合EntityRepositoryType符号如在公共基类实体上声明一起使用。EntityRepository类中还保留了完整的查询与映射 API如findOneOrFail、findAll、findAndCount、findByCursor、nativeUpdate、nativeDelete、upsert/upsertMany、count/countBy、getReference、populate、create/assign/merge等它们与 EntityManager 的同名方法一一对应均为转发实现详见 EntityRepository.ts。小结MikroORM 的仓储层设计遵循薄封装 扩展点原则默认EntityRepository只是携带实体类型的 EntityManager 转发器需要复用查询逻辑时通过Entity({ customRepository: () MyRepository })注册实体级自定义仓储并通过EntityRepositoryType符号获得完整的类型推断需要全局统一扩展时用MikroORM.init({ entityRepository: BaseRepository })配置基类仓储。v6 移除仓储上的持久化方法进一步明确了仓储与 EntityManager 的分工边界——持久化交给 EntityManager仓储专注查询与领域逻辑的封装。相关参考官方文档 docs/docs/repositories.mdv5.9 版本对应 docs/versioned_docs/version-5.9/repositories.md、核心实现 packages/core/src/entity/EntityRepository.ts、packages/core/src/EntityManager.ts、packages/core/src/utils/Configuration.ts测试范例 tests/features/decorators/legacy/decorators.test.ts。赞分享后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载相关推荐ASP.NET Boilerplate 仓储模式Repository Pattern完全指南从默认仓储到自定义实现与最佳实践ASP.NET Boilerplate 仓储模式Repository Pattern完全指南从默认仓储到自定义实现与最佳实践 导读 仓储Reposito后端Web框架依赖注入认证鉴权Gutenberg wordpress/data Persistence Plugin 实战解析从 localStorage 默认存储到自定义存储的完整指南Gutenberg wordpress/data Persistence Plugin 实战解析从 localStorage 默认存储到自定义存储的完整指南后端前端iloader 侧载指南如何读懂全局状态设计SideloaderMutex 与 DeviceInfoMutex 协作解析iloader 侧载指南如何读懂全局状态设计SideloaderMutex 与 DeviceInfoMutex 协作解析 iloader 是一款用户友好的桌面应用移动开发上一篇AngularJS Material v1.2 升级迁移指南破坏性变更详解与实战对照下一篇免费炉石传说模改插件HsMod终极指南让游戏体验提升300%创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考