TypeScripti põhiandmete haldamine: juhend viiteandmete tüüpide rakendamiseks

Ettevõtte tarkvaraarenduse keerulises maailmas on andmed iga rakenduse eluallikas. See, kuidas me neid andmeid haldame, salvestame ja kasutame, mõjutab otseselt meie süsteemide vastupidavust, hooldatavust ja skaleeritavust. Oluline osa nendest andmetest on põhiandmed—ettevõtte peamised, mitte-tehingulised üksused. Selles valdkonnas on viiteandmed on tegevusala alustala. See artikkel pakub arendajatele ja arhitektidele põhjaliku juhendi viiteandmete tüüpide rakendamiseks ja haldamiseks TypeScripti abil, muutes levinud vigade ja vastuolude allika tüübihoidva terviklikkuse kindluseks.

Miks on viiteandmete haldamine tänapäevastes rakendustes oluline

Enne koodi sukeldumist selgitagem oma peamised kontseptsioonid.

Põhiandmete haldamine (MDM) on tehnoloogiapõhine distsipliin, kus äri ja IT teevad koostööd, et tagada ettevõtte ametlike jagatud põhiandmete varade ühtsus, täpsus, haldus, semantiline järjepidevus ja vastutus. Põhiandmed esindavad ettevõtte "nimisõnu", nagu kliendid, tooted, töötajad ja asukohad.

Viiteandmed on spetsiifiline põhiandmete tüüp, mida kasutatakse muude andmete klassifitseerimiseks või kategooriateks liigitamiseks. Need on tavaliselt staatilised või muutuvad väga aeglaselt. Mõelge sellele kui eelnevalt määratletud väärtuste kogumile, mida konkreetne väli võib võtta. Levinud näited kogu maailmast hõlmavad:

• Riikide loend (nt Ameerika Ühendriigid, Saksamaa, Jaapan)
• Valuutakoodid (USD, EUR, JPY)
• Tellimuse olekud (Ootel, Töötlemisel, Saadetud, Tarnitud, Tühistatud)
• Kasutajarollid (administraator, toimetaja, vaataja)
• Tootekategooriad (elektroonika, rõivad, raamatud)

Viiteandmete väljakutse ei seisne nende keerukuses, vaid nende laialdases levikus. See ilmneb kõikjal: andmebaasides, API-päringutes, äriloogikas ja kasutajaliidestes. Kui neid halvasti hallatakse, põhjustab see probleemide kaskaadi: andmete vastuolu, tööajalised vead ja raskesti hooldatav ja ümberkujundatav koodibaas. Siin muutub TypeScript oma võimsa staatilise tüübistussüsteemiga asendamatuks tööriistaks andmehaldusõiguse tagamiseks juba arendusetapis.

Põhiprobleem: "maagiliste stringide" ohud

Illustreerime probleemi levinud stsenaariumiga: rahvusvaheline e-kaubanduse platvorm. Süsteem peab jälgima tellimuse olekut. Naiivne rakendus võib hõlmata toorete stringide otsest kasutamist koodis:

            
function processOrder(orderId: number, newStatus: string) {
  if (newStatus === 'shipped') {
    // Laevanduse loogika
    console.log(`Tellimus ${orderId} on saadetud.`);
  } else if (newStatus === 'delivered') {
    // Tarnimise kinnituse loogika
    console.log(`Tellimus ${orderId} on kinnitatud tarnituks.`);
  } else if (newStatus === 'pending') {
    // ...ja nii edasi
  }
}

// Kuskil mujal rakenduses...
processOrder(12345, 'Shipped'); // Oh ei, trükiviga!

            

              
                Copy
              
            
          

See lähenemisviis, mis tugineb sageli nn "maagilistele stringidele", on täis ohte:

• Trükivead: Nagu ülalpool näidatud, võivad "shipped" vs "Shipped" põhjustada peeneid vigu, mida on raske tuvastada. Kompilaator ei paku abi.
• Avastatavuse puudumine: Uuel arendajal pole lihtsat võimalust teada saada, millised on kehtivad olekud. Nad peavad kogu koodibaasi läbi otsima, et leida kõik võimalikud stringiväärtused.
• Hooldusõud: Mis siis, kui ettevõte otsustab "shipped" muuta "dispatched"-ks? Te peaksite tegema riskantse kogu projekti hõlmava otsingu ja asendamise, lootes, et te ei jäta ühtegi eksemplari välja ega muuda kogemata midagi seostamata.
• Ühtse tõe allika puudumine: Kehtivad väärtused on rakenduses hajutatud, mis viib võimalike vastuoludeni esipaneeli, tagapaneeli ja andmebaasi vahel.

Meie eesmärk on need probleemid kõrvaldada, luues ühe autoriteetse allika meie viiteandmete jaoks ja kasutades TypeScripti tüübisüsteemi selle õige kasutamise tagamiseks kõikjal.

Viiteandmete alustalad TypeScripti mustrid

TypeScript pakub viiteandmete haldamiseks mitmeid suurepäraseid mustreid, millel igaühel on oma eelised ja puudused. Vaatame üle kõige levinumad, klassikalisest moodsaimate parimate tavadeni.

Lähenemisviis 1: Klassikaline `enum`

Paljude arendajate jaoks, kes on pärit Java või C#-i sarnastest keeltest, on `enum` selle tööriista kõige tuttavam tööriist. See võimaldab teil määratleda nimetatud konstantide komplekti.

            
export enum OrderStatus {
  Pending = 'PENDING',
  Processing = 'PROCESSING',
  Shipped = 'SHIPPED',
  Delivered = 'DELIVERED',
  Cancelled = 'CANCELLED',
}

function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === OrderStatus.Shipped) {
    console.log(`Tellimus ${orderId} on saadetud.`);
  }
}

processOrder(123, OrderStatus.Shipped); // Korrektne ja tüübihoidlik
// processOrder(123, 'SHIPPED'); // Kompileerimisaja viga! Suurepärane!

            

              
                Copy
              
            
          

Plussid:

• Selge kavatsus: See märgib selgelt, et te defineerite seotud konstantide komplekti. Nimi `OrderStatus` on väga kirjeldav.
• Nominaalne tüübistamine: `OrderStatus.Shipped` ei ole lihtsalt string "SHIPPED"; see on tüüpi `OrderStatus`. See võib mõnes stsenaariumis pakkuda tugevamat tüübikontrolli.
• Loetavus: `OrderStatus.Shipped` peetakse sageli loetavamaks kui toorest stringi.

Miinused:

• JavaScripti jalajälg: TypeScripti enumid ei ole ainult kompileerimisaja konstruktsioon. Need loovad koostatud väljundisse JavaScripti objekti (kohese käivitatava funktsiooni avaldise ehk IIFE), mis suurendab teie kimbus suurust.
• Numbritega enumide keerukus: Kuigi me kasutasime siin stringe nimega enumid (mis on soovitatav tava), võivad TypeScripti vaike-numbrilised enumid olla segadust tekitava pöördkaardistamise käitumisega.
• Vähem paindlik: Nende tuletamine ilma lisatööta täiendkujundustest või keerukamate andmestruktuuride jaoks on keerulisem.

Lähenemisviis 2: Kergekaalulised stringide liitliidud

Kergem ja täiesti tüübipõhine lähenemisviis on kasutada stringide liitliite. See muster määratleb tüübi, mis võib olla ainult üks konkreetse stringide komplekti hulgast.

            
export type OrderStatus = 
  | 'PENDING'
  | 'PROCESSING'
  | 'SHIPPED'
  | 'DELIVERED'
  | 'CANCELLED';

function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === 'SHIPPED') {
    console.log(`Tellimus ${orderId} on saadetud.`);
  }
}

processOrder(123, 'SHIPPED'); // Korrektne ja tüübihoidlik
// processOrder(123, 'shipped'); // Kompileerimisaja viga! Vinge!

            

              
                Copy
              
            
          

Plussid:

• Null JavaScripti jalajälg: "type" määratlused kustutatakse kompileerimise ajal täielikult. Need eksisteerivad ainult TypeScripti kompilaatori jaoks, mille tulemuseks on puhtam ja väiksem JavaScript.
• Lihtsus: Süntaks on otsekohene ja kergesti mõistetav.
• Suurepärane automaatne täitmine: Koodiredaktorid pakuvad selle tüübiga muutujate jaoks suurepärast automaatset täitmist.

Miinused:

• Tööajalise artefakti puudumine: See on nii pluss kui ka miinus. Kuna see on ainult tüüp, ei saa te tööajal võimalikke väärtusi üle lugeda (nt rippmenüü täitmiseks). Te peaksite määrama eraldi konstantide massiivi, mis toob kaasa teabe dubleerimise.

            
// Väärtuste dubleerimine
export type OrderStatus = 'PENDING' | 'PROCESSING' | 'SHIPPED';

export const ALL_ORDER_STATUSES = ['PENDING', 'PROCESSING', 'SHIPPED'];

            

              
                Copy
              
            
          

See dubleerimine on selge "Ära korda ennast" (DRY) põhimõtte rikkumine ja potentsiaalne vigade allikas, kui tüüp ja tööajalised väärtused langevad sünkroonist välja. See viib meid moodsaima, eelistatud lähenemisviisini.

Lähenemisviis 3: `const` kinnituse võimendusmäng (kuldne standard)

TypeScript 3.4-s tutvustatud `as const` kinnitus pakub täiuslikku lahendust. See ühendab mõlema maailma parimad küljed: üks tõe allikas, mis eksisteerib tööajal, ja tuletatud, täiuslikult tüübitud liit, mis eksisteerib kompileerimise ajal.

Siin on muster:

            
// 1. Määrake tööajalised andmed "as const"-ga
export const ORDER_STATUSES = [
  'PENDING',
  'PROCESSING',
  'SHIPPED',
  'DELIVERED',
  'CANCELLED',
] as const;

// 2. Tuletage tüüp töölistest andmetest
export type OrderStatus = typeof ORDER_STATUSES[number];
//   ^? type OrderStatus = "PENDING" | "PROCESSING" | "SHIPPED" | "DELIVERED" | "CANCELLED"

// 3. Kasutage seda oma funktsioonides
function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === 'SHIPPED') {
    console.log(`Tellimus ${orderId} on saadetud.`);
  }
}

// 4. Kasutage seda tööajal JA kompileerimise ajal
processOrder(123, 'SHIPPED'); // Tüübihoidlik!

// Ja te saate seda hõlpsasti UI-de jaoks üle lugeda!
function getStatusOptions() {
  return ORDER_STATUSES.map(status => ({ value: status, label: status.toLowerCase() }));
}

            

              
                Copy
              
            
          

Selgitagem, miks see nii võimas on:

• `as const` ütleb TypeScriptile, et ta tuletaks kõige täpsemat võimalikku tüüpi. "string[]" asemel tuletab see tüüpi kui `readonly ['PENDING', 'PROCESSING', ...]`. "readonly" modifikaator takistab massiivi juhuslikku muutmist.
• `typeof ORDER_STATUSES[number]` on maagia, mis tuletab tüübi. See ütleb: "andke mulle `ORDER_STATUSES` massiivi sees olevate elementide tüüp." TypeScript on piisavalt tark, et näha spetsiifilisi stringi literaale ja loob neist liittüübi.
• Ühtne tõe allikas (SSOT): `ORDER_STATUSES` massiiv on ainus koht, kus need väärtused on määratletud. Tüüp tuletatakse sellest automaatselt. Kui lisate massiivi uue oleku, värskendub `OrderStatus` tüüp automaatselt. See kõrvaldab igasuguse võimaluse, et tüüp ja tööajalised väärtused muutuvad sünkroonist välja.

See muster on moodne, idioomiline ja vastupidav viis lihtsate viiteandmete käsitlemiseks TypeScriptis.

Täiustatud rakendamine: keerukate viiteandmete struktureerimine

Viiteandmed on sageli keerukamad kui lihtne stringide loend. Kaaluge riikide loendi haldamist saatelehe vormi jaoks. Igal riigil on nimi, kahetäheline ISO-kood ja numbrivalimispiir. "as const" muster skaalub selle jaoks kaunilt.

Andmekogumi määratlemine ja salvestamine

Esiteks loome oma ühe tõe allika: objektide massiivi. Rakendame sellele `as const`, et muuta kogu struktuur sügavalt ainult lugemiseks ja täpse tüübi tuletamise võimaldamiseks.

            
export const COUNTRIES = [
  {
    code: 'US',
    name: 'United States of America',
    dial: '+1',
    continent: 'North America',
  },
  {
    code: 'DE',
    name: 'Germany',
    dial: '+49',
    continent: 'Europe',
  },
  {
    code: 'IN',
    name: 'India',
    dial: '+91',
    continent: 'Asia',
  },
  {
    code: 'BR',
    name: 'Brazil',
    dial: '+55',
    continent: 'South America',
  },
] as const;

            

              
                Copy
              
            
          

Täpsete tüüpide tuletamine kogumist

Nüüd saame sellest andmestruktuurist otse tuletada väga kasulikke ja spetsiifilisi tüüpe.

            
// Tuletage ühe riigiobjekti tüüp
export type Country = typeof COUNTRIES[number];
/*
  ^? type Country = {
      readonly code: "US";
      readonly name: "United States of America";
      readonly dial: "+1";
      readonly continent: "North America";
  } | {
      readonly code: "DE";
      ... 
  }
*/

// Tuletage kõigi kehtivate riigikoodide liittüüp
export type CountryCode = Country['code']; // või `typeof COUNTRIES[number]['code']`
//   ^? type CountryCode = "US" | "DE" | "IN" | "BR"

// Tuletage kõigi kontinentide liittüüp
export type Continent = Country['continent'];
//   ^? type Continent = "North America" | "Europe" | "Asia" | "South America"

            

              
                Copy
              
            
          

See on uskumatult võimas. Ilma ühtegi redundantse tüübi määratluse rida kirjutamata oleme loonud:

1. `Country` tüüp, mis esindab riigiobjekti kuju.
2. `CountryCode` tüüp, mis tagab, et mis tahes muutuja või funktsiooni parameeter võib olla ainult üks kehtiv, olemasolev riigikood.
3. `Continent` tüüp riikide kategoriseerimiseks.

Kui lisate `COUNTRIES` massiivi uue riigi, värskenduvad kõik need tüübid automaatselt. See on kompilaatori poolt tagatud andmete terviklikkus.

Keskselt viiteandmete teenuse loomine

Rakenduse kasvades on parim tava viiteandmetele juurdepääsu tsentraliseerida. Seda saab teha lihtsa mooduli või formaalsema teenuseklassi kaudu, mida sageli rakendatakse singlton-mustri abil, et tagada kogu rakenduses üks eksemplar.

Moodulipõhine lähenemisviis

Enamiku rakenduste jaoks piisab ja on elegantne lihtsast moodulist, mis ekspordib andmeid ja mõningaid utiliitfunktsioone.

            
// fail: src/services/referenceData.ts

// ... (meie COUNTRIES konstant ja ülaltoodud tuletatud tüübid)

export const getCountries = () => COUNTRIES;

export const getCountryByCode = (code: CountryCode): Country | undefined => {
  // "find" meetod on siin täiesti tüübihoidlik
  return COUNTRIES.find(country => country.code === code);
};

export const getCountriesByContinent = (continent: Continent): Country[] => {
  return COUNTRIES.filter(country => country.continent === continent);
};

// Vajadusel saate eksportida ka tooreid andmeid ja tüüpe
export { COUNTRIES, Country, CountryCode, Continent };

            

              
                Copy
              
            
          

See lähenemisviis on puhas, testitav ja kasutab ES mooduleid loomuliku singlton-laadse käitumise jaoks. Teie rakenduse mis tahes osa saab nüüd importida neid funktsioone ja saada ühtlast, tüübihoidlikku juurdepääsu viiteandmetele.

Asünkroonselt laaditavate viiteandmete käsitlemine

Paljudes reaalsetes ettevõttesüsteemides pole viiteandmed esipaneelis kõvasti kodeeritud. Need laaditakse tagantjärele API-st, et tagada nende pidev värskendatus kõigi klientide vahel. Meie TypeScripti mustrid peavad seda arvestama.

Peamine on luua kliendipoolsed tüübid, mis vastavad oodatavale API-vastusele. Seejärel saame kasutada tööajaliste valideerimisraamatukogusid, nagu Zod või io-ts, et tagada API-vastus tegelikult vastab meie tüüpidele tööajal, sildades dünaamilise API-loomuse ja TypeScripti staatilise maailma vahel.

            
import { z } from 'zod';

// 1. Määrake ühe riigi skeem Zod-i abil
const CountrySchema = z.object({
  code: z.string().length(2),
  name: z.string(),
  dial: z.string(),
  continent: z.string(),
});

// 2. Määrake API-vastuse skeem (riikide massiiv)
const CountriesApiResponseSchema = z.array(CountrySchema);

// 3. Tuletage TypeScripti tüüp Zod-skeemist
export type Country = z.infer;

// Saame ikka kooditüübi, kuid see on "string", kuna me ei tea väärtusi ette.
// Kui loend on väike ja fikseeritud, saate kasutada z.enum(['US', 'DE', ...]) täpsema tüübi jaoks.
export type CountryCode = Country['code'];

// 4. Teenus andmete laadimiseks ja vahemällu salvestamiseks
class ReferenceDataService {
  private countries: Country[] | null = null;

  async fetchAndCacheCountries(): Promise {
    if (this.countries) {
      return this.countries;
    }

    const response = await fetch('/api/v1/countries');
    const jsonData = await response.json();

    // Tööajaliste valideerimine!
    const validationResult = CountriesApiResponseSchema.safeParse(jsonData);

    if (!validationResult.success) {
      console.error('API-st pärinevad valed riigiandmed:', validationResult.error);
      throw new Error('Viiteandmete laadimine ebaõnnestus.');
    }

    this.countries = validationResult.data;
    return this.countries;
  }
}

export const referenceDataService = new ReferenceDataService();

            

              
                Copy
              
            
          

See lähenemisviis on äärmiselt vastupidav. See pakub kompileerimisaja turvalisust tuletatud TypeScripti tüüpide kaudu ja tööajaliste turvalisust, valideerides, et välisest allikast pärinevad andmed vastavad oodatavale kujule. Rakendus saab käivitamisel kutsuda `referenceDataService.fetchAndCacheCountries()`, et tagada andmete vajaduse korral kättesaadavus.

Viiteandmete integreerimine teie rakendusse

Tugeva aluse loomisega muutub selle tüübihoidliku viiteandmete kasutamine kogu teie rakenduses lihtsaks ja elegantseks.

UI-komponentides (nt React)

Mõelge riigi valimiseks rippmenüü komponenti. Meie varem tuletatud tüübid muudavad komponendi atribuudid selgeks ja turvaliseks.

            
import React from 'react';
import { COUNTRIES, CountryCode } from '../services/referenceData';

interface CountrySelectorProps {
  selectedValue: CountryCode | null;
  onChange: (newCode: CountryCode) => void;
}

export const CountrySelector: React.FC = ({ selectedValue, onChange }) => {
  return (
     onChange(e.target.value as CountryCode)}
    >
      Valige riik
      {COUNTRIES.map((country) => (
        
          {country.name} ({country.code})
        
      ))}
    
  );
};

            

              
                Copy
              
            
          

Siin tagab TypeScript, et `selectedValue` peab olema kehtiv `CountryCode` ja `onChange` tagasikutse saab alati kehtiva `CountryCode`.

Äriloogikas ja API-kihtides

Meie tüübid takistavad kehtimatute andmete levikut süsteemis. Kõik selle andmestikuga töötavad funktsioonid saavad lisaturvalisusest kasu.

            
import { OrderStatus } from '../services/referenceData';

interface Order {
  id: string;
  status: OrderStatus;
  items: any[];
}

// Seda funktsiooni saab kutsuda ainult kehtiva olekuga.
function canCancelOrder(order: Order): boolean {
  // Pole vaja kontrollida trükivigu nagu 'pendng' või 'Procesing'
  return order.status === 'PENDING' || order.status === 'PROCESSING';
}

const myOrder: Order = { id: 'xyz', status: 'SHIPPED', items: [] };

if (canCancelOrder(myOrder)) {
  // See plokk ei täida (korrektne ja turvaliselt).
}

            

              
                Copy
              
            
          

Rahvusvahelistumiseks (i18n)

Viiteandmed on sageli rahvusvahelistumise peamine komponent. Saame oma andmemudelit laiendada, et lisada tõlkimisklahve.

            
export const ORDER_STATUSES = [
  { code: 'PENDING', i18nKey: 'orderStatus.pending' },
  { code: 'PROCESSING', i18nKey: 'orderStatus.processing' },
  { code: 'SHIPPED', i18nKey: 'orderStatus.shipped' },
] as const;

export type OrderStatusCode = typeof ORDER_STATUSES[number]['code'];

            

              
                Copy
              
            
          

UI-komponent saab seejärel kasutada `i18nKey`-d kasutaja praeguse keele jaoks tõlgitud stringi otsimiseks, samal ajal kui äriloogika jätkab stabiilse, muutumatu `code`-ga töötamist.

Juhtimis- ja hooldustavad parimad tavad

Nende mustrite rakendamine on suurepärane algus, kuid pikaajaline edu nõuab head juhtimist.

• Ühtne tõe allikas (SSOT): See on kõige olulisem põhimõte. Kõik viiteandmed peaksid pärinema ühest ja ainult ühest autoriteetsest allikast. Esipaneeli rakenduse jaoks võib see olla üks moodul või teenus. Suuremas ettevõttes on see sageli spetsiaalne MDM-süsteem, mille andmed on API kaudu kättesaadavad.
• Selge omand: Määrake meeskond või üksikisik, kes vastutab viiteandmete täpsuse ja terviklikkuse eest. Muudatused peaksid olema tahtlikud ja hästi dokumenteeritud.
• Versioneerimine: Kui viiteandmeid laaditakse API-st, versioonige oma API lõpp-punkte. See takistab andmestruktuuri purustavaid muudatusi vanemate klientide mõjutamast.
• Dokumenteerimine: Kasutage JSDoc-i või muid dokumenteerimistööriistu iga viiteandme kogumi tähenduse ja kasutuse selgitamiseks. Dokumenteerige näiteks iga `OrderStatus`-i ärilised reeglid.
• Mõelge koodi genereerimisele: Parima sünkroonimise tagamiseks tagapaneeli ja esipaneeli vahel kaaluge tööriistade kasutamist, mis genereerivad TypeScripti tüübid otse teie tagantjärele API spetsifikatsioonist (nt OpenAPI/Swagger). See automatiseerib kliendipoolsete tüüpide sünkroonimise API andmestruktuuridega.

Järeldus: andmete terviklikkuse tõstmine TypeScriptiga

Põhiandmete haldamine on distsipliin, mis laieneb koodist kaugemale, kuid arendajatena oleme oma rakenduste andmete terviklikkuse viimased väravavahid. Liikudes eemale habrastest "maagilistest stringidest" ja omaks võttes kaasaegseid TypeScripti mustreid, saame tõhusalt kõrvaldada tavaliste vigade terve klassi.

`as const` muster koos tüüpide tuletamisega pakub vastupidavat, hooldatavat ja elegantset lahendust viiteandmete haldamiseks. See loob ühtse tõe allika, mis teenib nii tööajalist loogikat kui ka kompileerimisaja tüübikontrollerit, tagades, et need ei saa kunagi sünkroonist välja. Kui see on kombineeritud tsentraliseeritud teenuste ja väliste andmete tööajaliste valideerimisega, loob see lähenemisviis võimsa raamistiku vastupidavate, ettevõtte tasemel rakenduste loomiseks.

Lõppkokkuvõttes on TypeScript rohkem kui lihtsalt vahend `null` või `undefined` vigade vältimiseks. See on võimas keel andmemodelleerimiseks ja äriliste reeglite otseseks sisseehitamiseks teie koodi struktuuri. Selle täieliku potentsiaali ärakasutamine viiteandmete haldamiseks loob tugevama, prognoositavama ja professionaalsema tarkvaratoote.