Miklix

„SysExtension Framework“ naudojimas norint sužinoti, kurį poklasį reikia sukurti „Dynamics AX 2012“

Paskelbta: 2025 m. vasario 16 d. 00:25:50 UTC

Šiame straipsnyje aprašoma, kaip naudoti mažai žinomą „SysExtension“ sistemą „Dynamics AX 2012“ ir „Dynamics 365 for Operations“, kad būtų sukurtos subklasės, pagrįstos atributų dekoracijomis, leidžiančios lengvai išplėsti apdorojimo klasių hierarchijos dizainą.


Šis puslapis buvo mašininiu būdu išverstas iš anglų kalbos, kad juo galėtų naudotis kuo daugiau žmonių. Deja, mašininis vertimas dar nėra tobula technologija, todėl gali pasitaikyti klaidų. Jei pageidaujate, originalią versiją anglų kalba galite peržiūrėti čia:

Using the SysExtension Framework to Find Out Which Subclass to Instantiate in Dynamics AX 2012

Šiame įraše pateikta informacija pagrįsta Dynamics AX 2012 R3. Jis gali galioti arba negalioja kitoms versijoms. (Atnaujinimas: galiu patvirtinti, kad šiame straipsnyje pateikta informacija galioja ir „Dynamics 365 for Operations“)

Diegdami apdorojimo klases Dynamics AX, dažnai susiduriate su klasių hierarchijos kūrimu, kurioje kiekvienas poklasis atitinka enum reikšmę arba turi kitą duomenų susiejimą. Klasikinis dizainas yra tada, kai super klasėje turi būti konstravimo metodas, turintis jungiklį, kuris pagal įvestį nustato, kurią klasę sukurti.

Tai iš principo veikia gerai, bet jei turite daug skirtingų galimų įvesčių (daugelis elementų sąraše arba galbūt įvestis yra kelių skirtingų reikšmių derinys), jį prižiūrėti gali būti varginantis ir gali kilti klaidų, o dizainas visada turi trūkumą, kad turėsite modifikuoti minėtą konstravimo metodą, jei kada nors pridėsite naują poklasį arba atliksite pakeitimus, kuris poklasis turėtų būti naudojamas pagal kurią įvestį.

Laimei, yra daug elegantiškesnis, bet, deja, ir daug mažiau žinomas būdas tai padaryti, būtent naudojant SysExtension sistemą.

Ši sistema naudojasi atributais, kuriuos galite naudoti norėdami papuošti savo poklasius, kad sistema galėtų išsiaiškinti, kuri poklasė turėtų būti naudojama tvarkyti. Jums vis tiek reikės konstravimo metodo, bet jei jis bus atliktas teisingai, niekada nereikės jo keisti pridedant naujų poklasių.

Pažvelkime į įsivaizduojamą pavyzdį ir pasakykite, kad ketinate įdiegti hierarchiją, kuri atlieka tam tikrą apdorojimą pagal InventTrans lentelę. Kokį apdorojimą reikia atlikti, priklauso nuo įrašų StatusReceipt ir StatusIssue, taip pat nuo to, ar įrašai yra susiję su „SalesLine“, „PurchLine“, ar ne. Jau dabar žiūrite į daugybę skirtingų derinių.

Tada sakykime, kad žinote, kad kol kas jums reikia tvarkyti tik keletą derinių, tačiau taip pat žinote, kad laikui bėgant jūsų bus paprašyta sugebėti valdyti vis daugiau derinių.

Laikykite tai gana paprasta ir sakykime, kad kol kas jums reikia tvarkyti tik su „SalesLine“ susijusius įrašus, kurių būsena yra ReservPhysical arba ReservOrdered, visų kitų derinių kol kas galima nepaisyti, bet kadangi žinote, kad vėliau turėsite juos tvarkyti, norėsite sukurti kodą taip, kad jį būtų galima lengvai išplėsti.

Jūsų hierarchija šiuo metu gali atrodyti maždaug taip:

  • „MyProcessor“.
    • „MyProcessor_Sales“.
      • MyProcessor_Sales_ReservOrdered
      • MyProcessor_Sales_ReservPhysical

Dabar galite lengvai įdiegti metodą super klasėje, kuri sukuria poklasį, pagrįstą ModuleInventPurchSales ir StatusIssue sąrašu. Bet tada turėsite modifikuoti superklasę kiekvieną kartą, kai pridedate poklasę, ir tai nėra paveldėjimo idėja objektinio programavimo atveju. Galų gale, jums nereikia keisti RunBaseBatch arba SysOperationServiceBase kiekvieną kartą, kai pridedate naują paketinę užduotį.

Vietoj to galite naudoti SysExtension sistemą. Tam reikės pridėti kitą klasę, kuri turi išplėsti SysAttribute. Ši klasė bus naudojama kaip atributas, kuriuo galėsite papuošti apdorojimo klases.

Ši klasė yra labai panaši į tai, kaip sukurtumėte duomenų sutarties klasę, skirtą SysOperation diegimui, nes joje bus keletas duomenų narių ir parm metodų, skirtų šioms reikšmėms gauti ir nustatyti.

Mūsų atveju klasės deklaracija gali atrodyti maždaug taip:

class MyProcessorSystemAttribute extends SysAttribute
{
    ModuleInventPurchSales  module;
    StatusIssue             statusIssue;
    StatusReceipt           statusReceipt
}

Turite sukurti naują () metodą visiems duomenų nariams sukurti. Jei norite, galite pateikti kai kurias arba visas numatytas reikšmes, bet aš to nepadariau.

public void new(ModuleInventPurchSales  _module,
                StatusIssue             _statusIssue,
                StatusReceipt           _statusReceipt)
{
    ;

    super();

    module          = _module;
    statusIssue     = _statusIssue;
    statusReceipt   = _statusReceipt;
}

Taip pat turėtumėte įdiegti parm metodą kiekvienam duomenų nariui, bet aš juos praleidau, nes esu tikras, kad žinote, kaip tai padaryti – kitu atveju laikykim tai pratimu ;-)

Dabar galite naudoti savo atributų klasę, kad papuoštumėte kiekvieną apdorojimo klasę. Pavyzdžiui, klasių deklaracijos gali atrodyti taip:

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::None,
                            StatusReceipt::None)]
class MyProcessor_Sales extends MyProcessor
{
}

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::ReservOrdered,
                            StatusReceipt::None)]
class MyProcessor_Sales_ReservOrdered extends MyProcessor_Sales
{
}

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::ReservPhysical,
                            StatusReceipt::None)]
class MyProcessor_Sales_ReservPhysical extends MyProcessor_Sales
{
}

Žinoma, galite pavadinti savo klases taip, kaip norite, čia svarbiausia yra tai, kad jūs papuošiate savo klases atributais, atitinkančiais jų apdorojimo būdą. (Tačiau atminkite, kad „Dynamics AX“ yra klasių hierarchijų pavadinimų suteikimo taisyklės ir, jei įmanoma, visada naudinga jų laikytis).

Dabar, kai papuošėte savo klases, kad nustatytumėte, kokį apdorojimą atlieka kiekviena iš jų, galite pasinaudoti SysExtension sistemos pranašumais, kad prireikus sukurtumėte poklasių objektus.

Savo super klasėje („MyProcessor“) galite pridėti tokį konstravimo metodą:

public static MyProcessor construct(ModuleInventPurchSales _module,
StatusIssue _statusIssue,
StatusReceipt _statusReceipt)
{
    MyProcessor                 ret;
    MyProcessorSystemAttribute  attribute;
    ;

    attribute = new MyProcessorSystemAttribute( _module,
                                                _statusIssue,
                                                _statusReceipt);

    ret = SysExtensionAppClassFactory::getClassFromSysAttribute(classStr(MyProcessor), attribute);

    if (!ret)
    {
        //  no class found
        //  here you could throw an error, instantiate a default
        //  processor instead, or just do nothing, up to you
    }

    return ret;
}

Tikrai įdomi dalis – ir iš tikrųjų viso šio įrašo objektas (atleiskite už kalambūrą) – yra metodas getClassFromSysAttribute() SysExtensionAppClassFactory klasėje. Šis metodas yra tai, kad jis priima hierarchijos super klasės pavadinimą (ir ši super klasė nebūtinai turi būti hierarchijos viršuje ; tai tiesiog reiškia, kad bus tinkamos tik šios klasės praplečiančios klasės) ir atributo objektą.

Tada jis grąžina klasės objektą, kuris išplečia nurodytą superklasę ir yra papuoštas atitinkamu atributu.

Akivaizdu, kad prie konstravimo metodo galite pridėti tiek daugiau patvirtinimo ar logikos, kiek norite, tačiau svarbu tai, kad įdiegus šį metodą daugiau niekada nereikės keisti. Galite pridėti poklasių į hierarchiją ir tol, kol įsitikinsite, kad jas tinkamai papuošėte, konstravimo metodas juos suras, net jei jie neegzistavo, kai buvo parašytas.

O našumas? Tiesą sakant, aš nebandžiau jo palyginti, bet nuoširdžiai jaučiu, kad tai tikriausiai veikia blogiau nei klasikinis jungiklio pareiškimo dizainas. Tačiau, atsižvelgiant į tai, kad daugiausiai Dynamics AX našumo problemų sukelia prieiga prie duomenų bazės, per daug dėl to nesijaudinčiau.

Žinoma, jei įgyvendinate kažką, dėl ko reikės greitai sukurti tūkstančius objektų, galbūt norėsite ištirti toliau, tačiau klasikiniais atvejais, kai tiesiog sukuriate vieną objektą, kad galėtumėte ilgai apdoroti, abejoju, ar tai bus svarbu. Be to, atsižvelgiant į mano trikčių šalinimo patarimą (kitą pastraipą), atrodo, kad SysExtension sistema priklauso nuo talpyklos saugojimo, todėl veikiančioje sistemoje abejoju, kad ji turi didelį našumą.Trikčių šalinimas: jei konstravimo metodas neranda jūsų poklasių, nors esate tikri, kad jie tinkamai dekoruoti, tai gali būti talpyklos problema. Pabandykite išvalyti talpyklą tiek kliente, tiek serveryje. Neturėtų būti būtina iš naujo paleisti AOS, bet tai gali būti paskutinė išeitis.

Pasidalinkite „Bluesky“.Dalintis FacebookBendrinkite „LinkedIn“.Bendrinkite „Tumblr“.Dalintis XBendrinkite „LinkedIn“.Prisegti prie Pinterest

Mikkel Bang Christensen

Apie autorių

Mikkel Bang Christensen
Mikkelis yra miklix.com kūrėjas ir savininkas. Jis turi daugiau nei 20 metų profesionalaus kompiuterių programuotojo ir programinės įrangos kūrėjo patirtį ir šiuo metu visą darbo dieną dirba didelėje Europos IT korporacijoje. Kai jis nerašo tinklaraščio, laisvalaikį skiria įvairiems interesams, pomėgiams ir užsiėmimams, kurie tam tikra prasme gali atsispindėti šioje svetainėje nagrinėjamų temų įvairovėje.