Denne artikkelen vil forklare avledet medlemmer i ECO. Det primære formål er å beskrive forskjellen mellom ReEvaluateSubscriber og ReSubscribeSubscriber parametere når du utlede medlemmer i kode.
En av de gode funksjonene i Fet som har gjort overgangen over i ECO er avledet medlemmer. En avledet medlem er litt som et beregnet felt på et datasett, bortsett fra det er bare beregnet første gang du be sin verdi og deretter at verdien er bufret til saksbehandlingstid.
Ta persons Fullname som et eksempel. Fullt navn ville bli beregnet som
Resultat: = Tittel + '' + Fornavn + '' + Lastname;
første viktige skritt for å skape en slik egenskap i ECO er å markere attributtet Avledet. Det er faktisk mulig å angi noen " Derivation OCL " og har ECO system utlede alt for deg
tittelen + '' + fornavn + '' + lastname
men denne artikkelen er ment å vise deg hvordan du skal håndtere mye mer kompliserte scenarier.
Med et typisk datasett beregnet feltet du forventer metoden som skal beregnes hver gang verdien blir forespurt. Hvis gjeldende objekt blir vist som en liste i aa Datagrid deretter ringer denne metoden for hvert enkelt tilfelle hver gang Datagrid Maler kan være CPU intensiv, spesielt hvis verdien beregnes ut fra mange andre attributter /objekter.
I ECO metoden utføres første gang verdien er forespurt, men da resultatet vil bli lagret automatisk i ECO plass. Fremtidige forespørsler om verdien av dette stammer medlem vil returnere den bufrede verdi i stedet. Potensialet for CPU å spare her er åpenbar, spesielt med kompliserte rutiner., En kode utledet metoden for et medlem har et bestemt navn + parameterliste, ECO bruker refleksjon for å finne den metoden. Strukturen er
funksjon < Member > DeriveAndSubscribe (ReEvaluateSubscriber, ReSubscribeSubscriber: ISubscriber): < medlemstype >;
i vår Fullname eksempel ECO forventer å finne
funksjon FullNameDeriveAndSubscribe (ReEvaluateSubscriber, ReSubscribeSubscriber: ISubscriber): string;
Problemet her er dette. Hvis verdien av Avledet medlem beregnes kun én gang, og deretter lagret, hva skjer hvis verdien av tittel, Fornavn, eller etternavn endringer?
ECO rammeverket åpenbart har ingen anelse om hva vi gjorde for å utlede verdien av dette medlem, og heller ikke hvilke andre gjenstander /medlemmer ble brukt til å beregne det. For å sikre at ECO aldri returnerer en feil verdi det er behov for å vite når dette medlem skal beregnes på nytt. Faktisk, hva det faktisk trenger å vite er når dette medlem skal merkes ". Ugyldig ", det vil ikke beregnes på nytt før verdien er bedt
ECO rammeverket bruker en slags observatør mønster for å se på aktuelle objekter /medlemmer , når en av disse er endret EcoSpace vil markere avledet medlem ugyldig (utlede et medlem via " Derivation OCL " vil plassere disse abonnementene automatisk). Så, våre koden ser nå noe sånt som dette
funksjonen FullNameDeriveAndSubscribe (ReEvaluateSubscriber, ReSubscribeSubscriber: ISubscriber): string; begynne Resultat: = Tittel + '' + Fornavn + '' + Lastname; //Nå legger vi eller " Abonnement " . Self.AsIObject () Properties [ 'tittel'] SubscribeToValue (ReEvaluateSubscriber.); . Self.AsIObject () Properties [ 'Fornavn'] SubscribeToValue (ReEvaluateSubscriber.); . Self.AsIObject () Properties [ 'Lastname'] SubscribeToValue (ReEvaluateSubscriber.); slutt;
" ReEvaluateSubscriber " er en observatør objekt som er sendt til oss fra et sted innenfor den interne driften av ECO rammeverket. Alt vi trenger å gjøre er å sørge for at vi abonnere det til alle relevante objekter /medlemmer. Når en av disse avhengige elementer har sin verdi endres, vil ReEvaluateSubscriber fortelle ECO rammeverk som verdien av eller medlem skal være " revurderes " Neste gang det blir forespurt.
revurdere eller abonnere på nytt? Dette bringer meg til det siste punktet. Det er to abonnenter sendes til vår metode, " ReEvaluateSubscriber " og " ReSubscribeSubscriber ", så hva gjør den andre gjør, og når bør det brukes
I forrige eksempel brukte vi ReEvaluateSubscriber fordi vi bare trengte å vite når verdiene i avdeling, Fornavn, eller Lastname endring?. I en mer komplisert eksempel kan vi trenger å gjøre noe mer strukturelt komplisert, som gjentar gjennom hver Ordrelinje av en PurchaseOrder og abonnere på medlemmer av de relaterte gjenstander i stedet.
I denne type situasjon, hva skjer hvis en ny Ordrelinje legges ? Vi kan ikke muligens allerede har abonnert på et objekt som ennå ikke hadde eksistert på det punktet vi plassert våre abonnementer? Hva om en Ordrelinje blir fjernet eller slettet?
Dette er akkurat hva ReSubscribeSubscriber er for. Dette abonnent skal utløses når vi ønsker å si " Dump alle abonnementene jeg plassert sist, la oss bare begynne på nytt ". I utgangspunktet er det ikke " Verdier " av elementene som er i endring, må vi erstatte våre abonnementer fordi det er mer /mindre objekter for å ta hensyn til
funksjon OrderValueDeriveAndSubscribe (ReEvaluateSubscriber, ReSubscribeSubscriber: ISubscriber). Desimalgrader; Var CurrentOrderLine: Ordrelinje; begynne Resultat: = 0; for CurrentOrderLine i Self.OrderLines gjøre begynne Resultat: = Resultat + CurrentOrderLine.LineValue; //Abonner på medlemmet av den nåværende barnet objektet CurrentOrderLine.AsIObject () Properties [ 'LineValue'] SubscribeToValue (ReEvaluateSubscriber),..
Slutten; //Slutt, hvis de Self.OrderLines listen endres på noen måte //vi trenger å skrap alle våre abonnement og starte på nytt. Self.AsIObject () Properties [ 'ordrelinjer'] SubscribeToValue (ReSubscribeSubscriber)..; slutt;
ConclusionHopefully dette har vært en øyeåpner som til evnene til kode-avledet medlemmer i ECO. Hvis du ikke allerede har gjort det jeg vil anbefale å lese Rolf Lampa artikkel Dynamisk navigasjon for høyere ytelse, ble det skrevet for Fet, men prinsippene er de samme.