Duke përdorur kornizën SysExtension për të gjetur se cila nënklasë do të instantiate në Dynamics AX 2012

Publikuar: 16 shkurt 2025 në 12:26:29 e paradites, UTC

Ky artikull përshkruan se si të përdoret kuadri pak i njohur SysExtension në Dynamics AX 2012 dhe Dynamics 365 për Operacionet për të instantiatuar nën-klasat bazuar në dekorimet e atributeve, duke lejuar një dizajn lehtësisht të ekzistueshëm të një hierarkie të klasës së përpunimit.

Kjo faqe u përkthye me makinë nga anglishtja për ta bërë të aksesueshme për sa më shumë njerëz. Fatkeqësisht, përkthimi me makinë nuk është ende një teknologji e përsosur, kështu që mund të ndodhin gabime. Nëse preferoni, mund ta shikoni versionin origjinal në anglisht këtu:

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

Informacioni në këtë postim bazohet në Dynamics AX 2012 R3. Mund të jetë ose jo e vlefshme për versione të tjera. (Update: Unë mund të konfirmoj se informacioni në këtë artikull është i vlefshëm edhe për Dynamics 365 për Operacionet)

Gjatë zbatimit të klasave të përpunimit në Dynamics AX, shpesh gjendeni përballë krijimit të një hierarkie klasore në të cilën çdo nënklasë korrespondon me një vlerë enum ose ka disa lidhje të tjera të të dhënave. Një dizajn klasik është që pastaj të ketë një metodë konstrukti në super klasën, e cila ka një switch që përcakton se cila klasë të instantiate bazuar në hyrje.

Kjo funksionon mirë në parim, por nëse keni shumë hyrje të ndryshme të mundshme (shumë elemente në një enum ose ndoshta hyrja është një kombinim i disa vlerave të ndryshme), ajo mund të bëhet e lodhshme dhe e prirur për gabime për t'u mbajtur dhe dizajni ka gjithmonë disavantazhin që do t'ju duhet të modifikoni metodën e ndërtimit të thënë nëse ndonjëherë shtoni një nënklasë të re ose bëni ndryshime në të cilat nënklasa duhet të përdoret bazuar në cilën hyrje.

Për fat të mirë, ekziston një mënyrë shumë më elegante, por fatkeqësisht edhe shumë më pak e njohur, për ta bërë këtë, pikërisht nga përdorimi i kuadrit SysExtension.

Ky kuadër përfiton nga atributet që mund të përdorni për të dekoruar nën-klasat tuaja për ta bërë sistemin në gjendje të kuptojë se cila nën-klasë duhet të përdoret për trajtimin e çfarë. Ju do të keni ende nevojë për një metodë konstrukti, por nëse bëhet siç duhet, ju kurrë nuk do të duhet ta modifikoni atë kur të shtoni nën-klasa të reja.

Le të shohim një shembull imagjinar dhe të themi se do të zbatoni një hierarki që bën një lloj përpunimi bazuar në tabelën InventTrans. Cili përpunim për të bërë varet nga StatusReceipt dhe StatusIssue e regjistrave, si dhe nga nëse regjistrat janë të lidhur me SalesLine, PurchLine ose asnjëra. Tashmë tani, ju jeni duke parë shumë kombinime të ndryshme.

Le të themi pastaj se ju e dini se tani për tani ju duhet vetëm të trajtojë një grusht të kombinimeve, por ju gjithashtu e dini se ju do të kërkohet për të qenë në gjendje për të trajtuar gjithnjë e më shumë kombinime me kalimin e kohës.

Le ta mbajmë relativisht të thjeshtë dhe të themi se tani për tani ju duhet vetëm të trajtoni regjistrimet lidhur me SalesLine me një StatusIssue të ReservPhysical ose ReservOrdered, të gjitha kombinimet e tjera mund të injorohen tani për tani, por meqë e dini se do t'ju duhet t'i trajtoni më vonë, ju do të dëshironi të projektoni kodin tuaj në një mënyrë që e bën atë lehtësisht të ekzistueshëm.

Hierarkia juaj mund të duket diçka e tillë tani për tani:

MyProcessor
- MyProcessor_Sales
  - MyProcessor_Sales_ReservOrdered
  - MyProcessor_Sales_ReservPhysical

Tani, ju mund të zbatoni lehtësisht një metodë në super klasë që instantiates një nënklasë bazuar në një ModuleInventPurchSales dhe një StatusIssue enum. Por më pas do t'ju duhet të modifikoni super klasën sa herë që shtoni një nën-klasë, dhe kjo nuk është në të vërtetë ideja e trashëgimisë në programimin e orientuar drejt objektit. Afterall, ju nuk keni nevojë të modifikoni RunBaseBatch ose SysOperationServiceBase sa herë që shtoni një punë të re lot.

Në vend të kësaj, ju mund të përdorni kornizën SysExtension. Kjo do t'ju kërkojë të shtoni një klasë tjetër, e cila duhet të zgjerojë SysAttribute. Kjo klasë do të përdoret si atribut me të cilin mund të dekoroni klasat tuaja të përpunimit.

Kjo klasë është shumë e ngjashme me mënyrën se si ju do të bënit një klasë të kontratës së të dhënave për një zbatim të SysOperation, në atë që do të ketë disa anëtarë të të dhënave dhe metoda parm për marrjen dhe vendosjen e këtyre vlerave.

Në rastin tonë, Deklarata e Klasës mund të duket diçka e tillë:

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

Ju duhet të bëni një metodë të re () për instantiating të gjithë anëtarët e të dhënave. Nëse dëshironi mund t'u jepni disa ose të gjitha vlera të prezgjedhura, por unë nuk e kam bërë këtë.

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

    super();

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

Dhe ju gjithashtu duhet të zbatoni një metodë parm për çdo anëtar të të dhënave, por unë i kam hequr ato këtu pasi jam i sigurt se ju e dini se si ta bëni këtë - përndryshe, le ta konsiderojmë si një ushtrim ;-)

Tani ju mund të përdorni klasën tuaj të atributeve për të dekoruar secilën nga klasat tuaja të përpunimit. Për shembull, deklaratat e klasës mund të duken kështu:

[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
{
}

Sigurisht që mund t'i emërtoni klasat tuaja në çdo mënyrë që dëshironi, pjesa e rëndësishme këtu është që të dekoroni klasat tuaja me atribute që korrespondojnë me atë lloj përpunimi që bëjnë. (Por kini parasysh se ka konventa emërtimi për hierarkitë e klasave në Dynamics AX dhe është gjithmonë një ide e mirë për të ndjekur ato, nëse është e mundur).

Tani që keni dekoruar klasat tuaja për të identifikuar se çfarë lloj përpunimi bën secila prej tyre, ju mund të përfitoni nga kuadri SysExtension për të çastit objektet e nën-klasave sipas nevojës.

Në super klasën tuaj (MyProcessor), ju mund të shtoni një metodë konstrukti si kjo:

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;
}

Pjesa me të vërtetë interesante - dhe me të vërtetë objekti (falni lojën) e gjithë këtij posti - është metoda getClassFromSysAttribute() në klasën SysExtensionAppClassFactory. Ajo që bën kjo metodë është se pranon emrin e super klasës së një hierarkie (dhe kjo super klasë nuk ka nevojë të jetë në krye të hierarkisë; kjo do të thotë thjesht se vetëm klasat që shtrijnë këtë klasë do të jenë të pranueshme) dhe një objekt atributi.

Pastaj kthen një objekt të një klase që zgjeron super klasën e specifikuar dhe është dekoruar me një atribut përkatës.

Ju padyshim mund të shtoni sa më shumë validim të mëtejshëm ose logjikë në metodën e ndërtimit si ju dëshironi, por e rëndësishme takeaway këtu është se pasi të zbatohet, ju kurrë nuk duhet të modifikoni këtë metodë përsëri. Ju mund të shtoni nën-klasa në hierarki dhe për aq kohë sa ju siguroheni për t'i dekoruar ato në mënyrë të përshtatshme, metoda e ndërtimit do t'i gjejë ato edhe pse ato nuk ekzistonin kur ajo ishte shkruar.

Po performanca? Sinqerisht nuk kam tentuar ta krahasoj, por ndjenja ime e zorrëve është se kjo ndoshta performon më keq se dizajni klasik i deklaratës së switch-it. Megjithatë, duke marrë parasysh se deri tani çështjet më të shumta të performancës në Dynamics AX janë shkaktuar nga aksesi në bazën e të dhënave, unë nuk do të shqetësohesha shumë për këtë.

Sigurisht, nëse jeni duke zbatuar diçka që do të kërkojë mijëra objekte për t'u krijuar shpejt, ju mund të dëshironi të hulumtoni më tej, por në rastet klasike kur ju vetëm instantiate një objekt të vetëm për të bërë disa përpunime të gjata, unë dyshoj se kjo do të ketë rëndësi. Gjithashtu, duke marrë parasysh bakshishin tim të dépanosjes (paragrafi tjetër), duket se kuadri SysExtension mbështetet në kaching, kështu që në një sistem të rrjedhshëm dyshoj se ka një goditje të rëndësishme të performancës. Dépanosje: Nëse metoda e ndërtimit nuk gjen klasat tuaja nën-klasat edhe pse jeni të sigurt se ato janë të dekoruara siç duhet, kjo mund të jetë një problem kaching. Provoni të pastroni cachet si në klient ashtu edhe në server. Nuk duhet të jetë e nevojshme të rifillohet në fakt AOS, por mund të jetë mjeti i fundit.