TypeORM เป็น ORM แบบ TypeScript-first สำหรับ Node.js มันพึ่งพา decorators ในการ map คลาสไปยังตาราง และรองรับทั้งรูปแบบ Active Record และ Data Mapper จุดดึงดูดที่ใหญ่ที่สุดคือการ integration กับ TypeScript อย่างลึกซึ้ง ส่วนความเสี่ยงที่ใหญ่ที่สุดคือขอบที่ขรุขระในชั้น query และประวัติการบำรุงรักษาที่ไม่สม่ำเสมอ
user.save()) สำหรับแอปเล็ก ๆ หรือ Data Mapper (repository.save(user)) สำหรับโค้ดที่ทดสอบได้และแยกส่วน@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 และ QueryBuilder มี type เพียงบางส่วน ชื่อ column ที่ผิดมักล้มเหลวตอน runtime ไม่ใช่ตอน compileBackend TypeScript ที่สร้างใหม่ (เข้าคู่กับ NestJS ได้อย่างเป็นธรรมชาติ) ทีมที่ให้ความสำคัญกับ models แบบ decorator และต้องการ entities ที่มี type และแอปที่ query ส่วนใหญ่เป็น CRUD โดยใช้ QueryBuilder เป็นครั้งคราว
การเลือก ORM เป็นข้อผูกมัดระยะยาวที่กำหนดรูปแบบว่าทุกฟีเจอร์แตะฐานข้อมูลอย่างไร ดีไซน์แบบ TypeScript-first ของ TypeORM เป็นชัยชนะด้านผลิตภาพที่แท้จริงสำหรับ codebase ที่มี type แต่ผู้สัมภาษณ์อยากได้ยินว่าคุณรู้ข้อจำกัดของมันด้วย — การ typing query เพียงบางส่วน, ความเจ็บปวดกับ query ที่ซับซ้อน และประวัติการ release ที่ขรุขระ — เพื่อให้คุณตัดสินใจได้ว่าเมื่อใด ergonomics ของมันคุ้มค่ากว่าขอบที่ขรุขระ แทนที่จะรับมันมาเพราะกระแส
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค