TypeORM est un ORM « TypeScript d'abord » pour Node.js. Il s'appuie sur les décorateurs (decorator) pour mapper les classes aux tables et prend en charge à la fois les patrons Active Record et Data Mapper. Son plus grand attrait est son intégration TypeScript poussée ; ses plus grands risques sont les aspérités de la couche requête et un historique de maintenance irrégulier.
user.save()) pour les petites applications, ou Data Mapper (repository.save(user)) pour un code testable et découplé.@Entity()
class User {
@PrimaryGeneratedColumn() id: number;
@Column({ unique: true }) email: string;
@OneToMany(() => Post, (p) => p.author) posts: Post[];
}
const users = await dataSource
.getRepository(User)
.find({ where: { email: "[email protected]" }, relations: { posts: true } });
find et le QueryBuilder ne sont que partiellement typés ; un mauvais nom de colonne échoue souvent à l'exécution, pas à la compilation.Backends TypeScript greenfield (il s'associe naturellement à NestJS), équipes qui valorisent les modèles à base de décorateurs et veulent des entités typées, et applications dont les requêtes sont surtout du CRUD avec un usage occasionnel du QueryBuilder.
Choisir un ORM est un engagement à long terme qui façonne la manière dont chaque fonctionnalité touche la base de données. La conception « TypeScript d'abord » de TypeORM est un vrai gain de productivité pour les bases de code typées, mais les recruteurs veulent vous entendre en connaître aussi les limites — typage partiel des requêtes, douleur des requêtes complexes et historique de versions chaotique — afin de décider quand son ergonomie l'emporte sur ses aspérités plutôt que de l'adopter par effet de mode.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don