TypeORM არის TypeScript-ზე ორიენტირებული ORM Node.js-ისთვის. ის ეყრდნობა decorator-ებს კლასების ცხრილებზე ასახვისთვის და მხარს უჭერს როგორც Active Record, ისე Data Mapper შაბლონს. მისი უდიდესი მიმზიდველობა 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 მხოლოდ ნაწილობრივ ტიპიზებულია; სვეტის არასწორი სახელი ხშირად runtime-ზე ვარდება, არა კომპილაციისას.ახალი (greenfield) TypeScript backend-ები (ბუნებრივად ერწყმის NestJS-ს), გუნდები, რომლებიც აფასებენ decorator-ზე დაფუძნებულ მოდელებს და უნდათ ტიპიზებული entity-ები, და აპლიკაციები, რომელთა query-ები ძირითადად CRUD-ია, ხანდახან QueryBuilder-ის გამოყენებით.
ORM-ის არჩევა გრძელვადიანი ვალდებულებაა, რომელიც აყალიბებს, როგორ ეხება ყოველი ფუნქცია მონაცემთა ბაზას. TypeORM-ის TypeScript-ზე ორიენტირებული დიზაინი ნამდვილი პროდუქტიულობის მოგებაა ტიპიზებული კოდის ბაზებისთვის, მაგრამ ინტერვიუერებს სურთ გაიგონ, რომ იცი მისი შეზღუდვებიც — query-ს ნაწილობრივი ტიპიზაცია, რთული query-ების ტკივილი და ხრეშიანი რელიზების ისტორია — რომ გადაწყვიტო, როდის აჭარბებს მისი ერგონომიკა უხეშ კიდეებს, ვიდრე hype-ის გამო მიიღებდე მას.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა