Etter at du har valgt MongoDB-databasen i systemet ditt, vil du sannsynligvis også bruke et ODM-bibliotek. Det mest populære er Mongoose eller et bibliotek bygget på toppen av det - Typegoose. I denne artikkelen vil vi dekke hovedforskjellene når vi jobber spesifikt med NestJS-rammeverket.
Du vet sannsynligvis allerede at Typegoose i hovedsak er en måte å bruke Mongoose med TypeScript, og det ville vært ditt kriterium når du velger biblioteket. Men det er litt mer til dette når du jobber med NestJS-rammeverket fordi det er et Mongoose-wrapper laget av NestJS-forfatterne - @nestjs/mongoose, og når du ser på syntaksen - ser den nesten identisk ut med Typegoose.
La oss bryte ned forskjellene mellom dem slik at det blir lettere å bestemme hvilken tilnærming du bør velge i prosjektet ditt - bruke @nestjs/mongoose-pakken eller Typegoose. Når du integrerer MongoDB med en NestJS-applikasjon, vil du finne eksempler og kodebiter som viser hvordan du setter opp en NestJS-applikasjon for å jobbe med MongoDB ved hjelp av TypeScript og pakker som Typegoose.
Hovedforskjeller
Tilkobling og modellinjeksjon med MongoDB-database
@nestjs/mongoose er et bibliotek dedikert til Nest-rammeverket, så det kommer med full støtte for DI-arbeidsflyten. På den annen side kan Typegoose brukes i ethvert annet NodeJS-prosjekt, så du må enten integrere det med Nest selv eller bruke fellesskapspakker.
Skjemadefinisjon
Selv om begge pakkene tillater definering av skjemaer ved hjelp av lignende dekoratører, varierer grensesnittene deres, og Typegoose tilbyr flere alternativer enn Nest-wrapperen. For eksempel - `@Schema()` dekoratøren tar kun Mongoose-definerte skjemaalternativer, mens `@modelOptions()` i tillegg til dette gir tilgang til en eksisterende tilkobling og noen tilpassede Typegoose-konfigurasjonsalternativer.
Med `@nestjs/mongoose`, hvis du vil manuelt endre skjema-definisjonen basert på metadata, kan du bruke `DefinitionsFactory` klassen. Denne tilnærmingen kan være nyttig når det er vanskelig å representere alt ved hjelp av dekoratører.
Klassemetoder
Begge pakkene tillater definisjon av instanser og statiske metoder. Her er eksempler på hvordan vi kan definere klassemetoder i begge pakkene:
Som du kan se, må vi opprette ekstra grensesnitt når vi bruker mongoose, Typegoose lar oss imidlertid få typeinformasjon fra klasser. Definisjonene er også mer naturlige ettersom de er inneholdt i en klasse som vanlige metoder. Med Nest-pakken må du bruke `statics` og `methods` egenskapene utenfor klassen, noe som litt reduserer lesbarheten og blir en mindre naturlig tilnærming når det gjelder å bruke klasser.
Hooks
Begge pakkene støtter hooks. I @nestjs/mongoose kan du bruke dem i fabrikkmetoden for modulimporter. Typegoose tilbyr støtte med @pre() og @post() dekoratører.
Tilpassede spørringsmetoder
Du kan legge til tilpassede spørringer i begge pakkene, men du vil sannsynligvis støte på typeproblemer i Mongoose. Forskjellen mellom en spørringsmetode og en statisk funksjon på modellen er at funksjonen ikke ville være kjedelig.
Virtuelle
Virtuelle egenskaper kan opprettes i Typegoose ved hjelp av ES6 get & set-funksjoner, mens du med Nest-pakken må bruke `virtual`-egenskapen utenfor klassen, noe som, i likhet med klassemetoder, føles mindre naturlig å jobbe med.
Hvilken bør du velge?
Selv om Mongoose allerede kan utlede typer fra skjema-definisjonen og dens Nest-wrapper har kule funksjoner, vil du fortsatt ha mer nytte av å bruke Typegoose. Det har også bedre dokumentasjon og fellesskapsstøtte. Spørsmålet er - har du tid og ressurser til å integrere Typegoose i prosjektet ditt med Nest? Hvis ja, ville jeg personlig gitt det en sjanse.
Sjekk også ut
