TypeORM ist ein TypeScript-first-ORM für Node.js. Es setzt auf Decorators, um Klassen auf Tabellen abzubilden, und unterstützt sowohl das Active-Record- als auch das Data-Mapper-Muster. Sein größter Reiz ist die tiefe TypeScript-Integration; seine größten Risiken sind raue Kanten auf der Query-Ebene und eine ungleichmäßige Wartungshistorie.
user.save()) für kleine Apps oder Data Mapper (repository.save(user)) für testbaren, entkoppelten Code.@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-Optionen und QueryBuilder sind nur teilweise typisiert; ein falscher Spaltenname scheitert oft zur Laufzeit, nicht zur Kompilierzeit.Greenfield-TypeScript-Backends (es passt natürlich zu NestJS), Teams, die Decorator-basierte Modelle schätzen und typisierte Entities wollen, und Apps, deren Queries überwiegend CRUD sind mit gelegentlichem QueryBuilder-Einsatz.
Die Wahl eines ORM ist eine langfristige Festlegung, die prägt, wie jedes Feature die Datenbank berührt. TypeORMs TypeScript-first-Design ist ein echter Produktivitätsgewinn für typisierte Codebasen, aber Interviewer wollen hören, dass du auch seine Grenzen kennst — teilweise Query-Typisierung, den Schmerz komplexer Queries und eine holprige Release-Historie — damit du entscheiden kannst, wann seine Ergonomie seine rauen Kanten überwiegt, statt es aus dem Hype heraus zu übernehmen.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden