ofdax: Dynamics AX 7 Codebase Architecture

[Blog bot]

Источник: http://ofdax.blogspot.com/2016/02/dy...hitecture.html
==============

It is probably the toughest topic for developers to grasp and get used to and the most cardinal change for internal code architecture. The idea as I see it is to make the huge standard codebase modular and loosely coupled and promote AX architects and developers to do the same with their code.
Packages, models and dependencies

In AX 2012 and before the whole application code existed within one namespace split by layers and models. You could call or reference any code in your Dynamics AX instance from any other place. We all know the upsides and downsides of this approach.
Easy to develop and modify, tough to upgrade and maintain. After years of typical, average-quality maintenance your codebase evolves into a clew of spaghetti code with continuously increasing entropy and TCO. That may eventually lead to “upgrade / re-implement / switch to another platform” decision. Let alone the painful upgrades throughout the system lifecycle.
In Dynamics AX 7 the standard codebase is split into a graph of separate packages with one-way dependencies among them. Model can only belong to a single package.

Code in package B can call (reference, extend, instantiate, subscribe to etc.) code from the same package or package A only of it has a dependency B –> A (B depends on A). Circular dependencies are not allowed or at least not recommended. Dependency is not transitive (A –> B, B –> C does not mean that A ­–> C). You will get a compilation error when trying to use an object from not references package.

The standard code is split into tens of packages, the most important among them are:
- Application platform – pure system code needed for AX to start.
- Application foundation – code shared by different modules like number sequences, data management, emailing etc.
- Application suite – the main AX business logic (AR, AP, Ledger etc.)
- Self-descriptive packages like Dimensions, Directory (GAB), Calendar, Currency and so on.
Needless to say that you should follow the same pattern when designing the internal architecture of your application. Take your time and imagine the consequences to the architecture of your solution.



Source code

Source code is stored in a hierarchical folder structure on disk of development box (e.g. C:\Packages) and / or in in VCS. Text Descriptor file contains metadata and the list of referenced packages. Objects are mainly stored as XML files.

Extensions and event-driven architecture

There is a new modification approach and a number of AOT nodes named “Extensions”. Extension is an object that lives within the same package or in a dependent package, and is incorporated into the object it extends by the Runtime.
For example, if you need to add a field to a table, a control or datasource to a form, you may create an extension without changing the initial object, and runtime with show a complete form with all its extensions.

Cool isn’t it? But what if you need to change behavior? Some eventing capabilities existed in AX 2012 but anyway you had to modify the initial object anyway in order to subscribe an event handler to its event.
In AX7, you may subscribe to pre-, post- events, system-predefined object events or developer-defined class delegates in declarative way, without changing the source object. Just decorate an event handler method with attributes defining the event. Event handler must be in the same or in a referenced package. And that is quite impressive, I need to say.

The downsides of such approach are also known:

• Poor code readability - you never know what is executed before or after your code. If you finish your method with “return 1;” it does not mean it will return one. There may be an unlimited number of post-handlers willing to override your and each other’s return values with unpredictable result.
• Not guaranteed sequenced of handler's’ execution.
• Cumbersome way of parsing and casting formal parameters and returning result at runtime. You have to use special vehicles to pass and receive them. And error-prone, too.
• Does not support all scenarios. You cannot not intrude into an arbitrary place of a method if there is no delegate.

Microsoft promises to increase the number of extension types and events so they can support most of the typical modifications. The currently supported may be found here:
There is another interesting patter of non-intrusive modifications though Plug-ins that did actuallyexisted in AX 2012 R3. In few words, It is an attribute- and data-driven replacement for switch-based class-factory construct pattern that you had to modify to incorporate a new class in a hierarchy. The support in standard code is quite limited though.



Making your code extensible

The flip side of this architecture is that in order to make your code extensible you have to use special patterns, like using in…Set instead is switch...case etc., specifically insert delegates into extensions points of your code. And that is definitely good as the more you think about your code architecture the longer and healthier your application will live.



Marketing view

Besides reduced maintenance and upgrade cost there is a marketing view on this: Plug-and-play approach to installation of third-party solutions. Just download it in a form of DLL(s) and that will plug into your codebase without tedious code merge etc. Ideally it should peacefully co-exist with other solutions you have.



Overlayering

Old good overlayering still exists, but in fact may be done only within one package and may eventually be abolished by Microsoft, meaning that once you’ll get a set of standard objects and events that you can extend or hook up to but never change or even see the source code.
That in fact means that layers only matter within one package. Let’s say you’re developing you own Fleet management application that overlayers and uses some standard code and also introduces new objects. Fleet booking in its turn is a customer-developed add-on to Fleet management. In AX 2012 you would create new models at proper layers.

In AX 7 you’ll probably face a tough choice. The recommended, way of development is to create your own package and not to modify any standard code but only extend and subscribe to its events. However, because the present extension mechanisms do not cover 100% of your modification scenarios you’ll probably have to have an overlayering part (e.g. in Application suite). And this overlayering part won’t be able to use any code from your main model, because the reference is already set in opposite direction (your package –> Appl. suite). Say, you cannot modify a lookup on SalesTable form and call your class from there.
One of possible solutions is to overlayer the standard objects, but keep the footprint of your changes as small as possible through e.g. declaring a delegate in the overlayered code.

Imagine you develop a Fleet management application in a separate package and you have to modify Application suite and Ledger logic but extensions do not support your scenarios. If you want to reuse e.g. an EDT like FMCustTable in all modifications, the structure of your application will have to evolve as follows:

Meaning you’ll have to spin-off some common code into a separate package for common use.

Deployment


The development side of the packaged architecture describe above is naturally reflected in changes to deployment techniques. There is no more source code in Production, only binary NuGet packages familiar to .NET developers. You create a deployment package in Visual Studio out of one or more source packages. The biggest collision so far is with overlayering. If you overlayer at list a single line in e.g. Application suite you’ll have to deliver the whole NuGet package and thus overwrite all changes at the target environment. The only known way to resolve this is to merge the source of the conflicting application which kills the idea of binary deployment.

Источник: http://ofdax.blogspot.com/2016/02/dy...hitecture.html

[Dreadlock]

Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать? Или в новой Аксапте можно залить свой Package и Аосы сами подхватят все изменения, как это сделано в ASP.Net?

[Morpheus]

Мне одному это не очень нравится?

[Vadik]

Цитата:

Сообщение от Dreadlock

Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать?

А в старой (2012) все как-то по-другому ?

[Dreadlock]

Цитата:

Сообщение от Vadik

А в старой (2012) все как-то по-другому ?

В том то и дело, что сейчас вроде как вектор направлен на веб интерфейс, и раз уж можно отдельный package публиковать (как я понял), было бы здорово не останавливать весь Prod

[Logger]

Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.

[Dreadlock]

Цитата:

Сообщение от Logger

Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.

+1

[EVGL]

Цитата:

Сообщение от Dreadlock

Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать? Или в новой Аксапте можно залить свой Package и Аосы сами подхватят все изменения, как это сделано в ASP.Net?

Мне было сказано, что да, сами подхватят.

[Dreadlock]

Цитата:

Сообщение от EVGL

Мне было сказано, что да, сами подхватят.

Сказка прям
Спасибо!

[trud]

Цитата:

Сообщение от Logger

Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.

вообще инсталляция делается через генерацию workbook, где вы указываете какие действия нужны. т.е. как сами напишите, так и будет. т.е. если у вас будет шаг - остановить IIS, то он выполнится
https://ax.help.dynamics.com/en/wiki...ackage-in-ax7/

для подхвата изменений я все же думаю придется перезапускать IIS. но вполне вероятно существует какой то способ обновления в кластере, когда обновляются только часть машин, вторая при этом продолжает работать. Аналогично тому-же обновлению кластера SQL Server

[trud]

ну а вообще конечно согласен с автором. т.е. в 2012 у вас было какое-нибудь маленькое решение с минимумом пересечений со стандартом(например один измененный не очень популярный енум или evenhandler на какой-нибудь private метод). вы его спокойненько поставляли клиентам как модель, не особо заботясь какие у клиента хотфиксы в основном приложении.
Сейчас же на енумы добавили сво-во IsExtensible которое по умолчанию везде False, создание event на методы помеченные как private запретили (что вообще выше моего понимания) и вы вынуждены делать overlaying, что автоматически приведет к тому, что в пакет с вашим решением добавляется чуть ли не все приложение целиком.
в общем из разряда хотели как лучше, а получилось как всегда

[gl00mie]

Звучит похоже на впечатления от 2012 RTM - значит, надо подождать AX7 R2

[belugin]

Цитата:

Сообщение от trud

создание event на методы помеченные как private запретили (что вообще выше моего понимания)

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

[S.Kuskov]

Цитата:

Сообщение от belugin

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

А без создания event как можно откастомизировать эту самую реализацию? По старинке?

[belugin]

Слои остались, но не уверен, что в клауде это разрешат делать, в on prem скорее всего будет

[gl00mie]

Цитата:

Сообщение от belugin

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..

[fed]

Вообще - я думаю что для микрософта первые года два DAX в Cloud будут шоком. Очень они много нового и интересного узнают о том как на самом деле делаются проекты, за что на самом деле клиент платит партнеру, много ли клиентов готовы переносить данные в облако и действительно ли клиенты готовы оплачивать накладные расходы на ведение разработки 'по правильному'. Это уже не говоря про ценовую политику и другие чисто коммерческие вещи.
В общем - Микрософт следует своему знаменитому корпоративному лозунгу "Слабоумие и отвага"...

[Ivanhoe]

Денис, например, в РФ в целом на облако в последнее время нормально смотрят. Только на облако в нормальном ЦОД с нормальным контрактом с владельцем ЦОДа. А в случае Azure - вообще не понятно какую ответственность несет MS, ЦОДа в РФ нет и т.п.

[fed]

А вы когда про облако рассказывали, не забыли сказать что разработка будет заметно дороже стоить, и что деплоймент теперь надо заранее планировать и тд и тп ?
То есть - я сам вполне себе за облако. Но только при условии что совокупная стоимость владения им не выше чем у стандартного решения...

[belugin]

Цитата:

Сообщение от gl00mie

Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..

У меня мысль такая.

По идее надо различать API и детали реализации, API это то, изменения чего можно хоть как-то контроллировать (т.е. разделять ломающие изменения и не ломающие).

Если выставлять все методы в API проще плюнуть и париться с ломающими изменениями. Т.е. объявление метода protected должно быть неким ответственным шагом.

С другой стороны, если потребитель принял решение поменять метод с private на protected, это вполне его право - он знает, что берет решение о поддержке этого куска на себя.

Сейчас пока не все готово для того, чтобы полностью отделить API от деталей реализации (Например нет InternalsVisibleTo что делает невозможным юниттестинг), но как-мне кажется, направление в уелом правильное - разделить поддерживаемые и неподдерживаемые модификации.