jaestevan: Embrace the extensions mindset with Dynamics 365 for Finance and Operations #2 – SysExtension framework [EN]

[Blog bot]

Источник: http://www.jaestevan.com/embrace-the...n-framework-en
==============

In my previous post Embrace the extensions mindset with Dynamics 365 for Finance and Operations we reflected on some of the patterns we can leverage to create our customizations by using only non-intrusive changes based on a real example: Adding a new Number Sequence to a standard module.

In particular, we discussed:

• Metadata Extensions — to add a new Enum Value in a standard Base Enum.
• Class Extensions — to add a new method to a standard class.
• Chain-of-Command — to add a block of code to an existing standard class method.
• Event-Handler subscription — to subscribe our own method to an existing standard delegate provided as an extension point.

If you still didn’t read that blog post, please take a moment now. If you already did it (thanks!), let’s continue with another pattern we have to consider: SysExtension Framework (also SysPlugin, that is quite similar).

This pattern allows us to create new sub-classes for factory methods without any over-layering or coupling with the original hierarchy. Therefore, we can add new sub-classes in our own packages without any intrusive modifications and replace a very common pattern, widely used all over the application, like this (taken from AX 2012 R3):

static SalesCopying construct(SalesPurchCopy salesPurchCopy)
{
switch(salesPurchCopy)
{
case SalesPurchCopy::CreditNoteHeader : return new SalesCopying_CreditNote();
case SalesPurchCopy::CreditNoteLines : return SalesCopyingCreditNoteLine::construct();

case SalesPurchCopy::CopyAllHeader :
case SalesPurchCopy::CopyAllLines :
case SalesPurchCopy::CopyJournalHeader :
case SalesPurchCopy::CopyJournalLines : return new SalesCopying();

//
case SalesPurchCopy::VoidFiscalDocument_BR : return new SalesCopying_VoidFiscalDocument_BR();
//

default : throw error(strFmt("@SYS19306",funcName()));
}

throw error(strFmt("@SYS19306",funcName()));
}

This pattern has many of problems to be extensible. The most obvious is likely the throw error on the default case, that makes impossible to an extension class to subscribe to the Post event on the method to add new cases. But even deleting this throw sentence (that has been indeed deleted in many standard methods as a quick way to make them extensible), the pattern itself is still a problem. If a new customer or partner customization or even a new standard module needs a new case, this class needs to be modified and the full package compiled and deployed.



Read the full article at “Dynamics AX in the Field”, the blog from the Premier Field Engineering team at Microsoft.





Источник: http://www.jaestevan.com/embrace-the...n-framework-en