AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.02.2016, 10:15   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
ofdax: Dynamics AX 7 Codebase Architecture
Источник: 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 inSet 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
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
За это сообщение автора поблагодарили: trud (3), Logger (1).
Старый 03.03.2016, 10:05   #2  
Dreadlock is offline
Dreadlock
Участник
Аватар для Dreadlock
 
298 / 219 (8) ++++++
Регистрация: 07.05.2009
Адрес: Москва
Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать? Или в новой Аксапте можно залить свой Package и Аосы сами подхватят все изменения, как это сделано в ASP.Net?
Старый 03.03.2016, 14:53   #3  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Мне одному это не очень нравится?
Старый 03.03.2016, 15:01   #4  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Dreadlock Посмотреть сообщение
Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать?
А в старой (2012) все как-то по-другому ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 03.03.2016, 15:09   #5  
Dreadlock is offline
Dreadlock
Участник
Аватар для Dreadlock
 
298 / 219 (8) ++++++
Регистрация: 07.05.2009
Адрес: Москва
Цитата:
Сообщение от Vadik Посмотреть сообщение
А в старой (2012) все как-то по-другому ?
В том то и дело, что сейчас вроде как вектор направлен на веб интерфейс, и раз уж можно отдельный package публиковать (как я понял), было бы здорово не останавливать весь Prod
Старый 03.03.2016, 15:11   #6  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.
Старый 03.03.2016, 15:14   #7  
Dreadlock is offline
Dreadlock
Участник
Аватар для Dreadlock
 
298 / 219 (8) ++++++
Регистрация: 07.05.2009
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.
+1
Старый 03.03.2016, 19:00   #8  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Dreadlock Посмотреть сообщение
Вот интересно, если я выкладываю package в Production, мне надо все АОС'ы перезапускать? Или в новой Аксапте можно залить свой Package и Аосы сами подхватят все изменения, как это сделано в ASP.Net?
Мне было сказано, что да, сами подхватят.
Старый 03.03.2016, 19:04   #9  
Dreadlock is offline
Dreadlock
Участник
Аватар для Dreadlock
 
298 / 219 (8) ++++++
Регистрация: 07.05.2009
Адрес: Москва
:)
Цитата:
Сообщение от EVGL Посмотреть сообщение
Мне было сказано, что да, сами подхватят.
Сказка прям
Спасибо!
Старый 04.03.2016, 02:27   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Logger Посмотреть сообщение
Безотносительно того как это было в 2012-й, хотелось бы уметь по живой накатывать, без передергивания аосов.
вообще инсталляция делается через генерацию workbook, где вы указываете какие действия нужны. т.е. как сами напишите, так и будет. т.е. если у вас будет шаг - остановить IIS, то он выполнится
https://ax.help.dynamics.com/en/wiki...ackage-in-ax7/

для подхвата изменений я все же думаю придется перезапускать IIS. но вполне вероятно существует какой то способ обновления в кластере, когда обновляются только часть машин, вторая при этом продолжает работать. Аналогично тому-же обновлению кластера SQL Server
За это сообщение автора поблагодарили: Logger (3).
Старый 04.03.2016, 03:02   #11  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
ну а вообще конечно согласен с автором. т.е. в 2012 у вас было какое-нибудь маленькое решение с минимумом пересечений со стандартом(например один измененный не очень популярный енум или evenhandler на какой-нибудь private метод). вы его спокойненько поставляли клиентам как модель, не особо заботясь какие у клиента хотфиксы в основном приложении.
Сейчас же на енумы добавили сво-во IsExtensible которое по умолчанию везде False, создание event на методы помеченные как private запретили (что вообще выше моего понимания) и вы вынуждены делать overlaying, что автоматически приведет к тому, что в пакет с вашим решением добавляется чуть ли не все приложение целиком.
в общем из разряда хотели как лучше, а получилось как всегда
Старый 04.03.2016, 08:54   #12  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Звучит похоже на впечатления от 2012 RTM - значит, надо подождать AX7 R2
Старый 04.03.2016, 09:05   #13  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
создание event на методы помеченные как private запретили (что вообще выше моего понимания)
Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.
Старый 04.03.2016, 09:21   #14  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от belugin Посмотреть сообщение
Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.
А без создания event как можно откастомизировать эту самую реализацию? По старинке?
Старый 04.03.2016, 10:20   #15  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Слои остались, но не уверен, что в клауде это разрешат делать, в on prem скорее всего будет
Старый 04.03.2016, 10:48   #16  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от belugin Посмотреть сообщение
Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.
Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..
За это сообщение автора поблагодарили: shogel (1).
Старый 04.03.2016, 11:26   #17  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Вообще - я думаю что для микрософта первые года два DAX в Cloud будут шоком. Очень они много нового и интересного узнают о том как на самом деле делаются проекты, за что на самом деле клиент платит партнеру, много ли клиентов готовы переносить данные в облако и действительно ли клиенты готовы оплачивать накладные расходы на ведение разработки 'по правильному'. Это уже не говоря про ценовую политику и другие чисто коммерческие вещи.
В общем - Микрософт следует своему знаменитому корпоративному лозунгу "Слабоумие и отвага"...
За это сообщение автора поблагодарили: Logger (1), gl00mie (1).
Старый 04.03.2016, 11:37   #18  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Денис, например, в РФ в целом на облако в последнее время нормально смотрят. Только на облако в нормальном ЦОД с нормальным контрактом с владельцем ЦОДа. А в случае Azure - вообще не понятно какую ответственность несет MS, ЦОДа в РФ нет и т.п.
__________________
Ivanhoe as is..
Старый 04.03.2016, 11:45   #19  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
А вы когда про облако рассказывали, не забыли сказать что разработка будет заметно дороже стоить, и что деплоймент теперь надо заранее планировать и тд и тп ?
То есть - я сам вполне себе за облако. Но только при условии что совокупная стоимость владения им не выше чем у стандартного решения...
Старый 04.03.2016, 11:54   #20  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..
У меня мысль такая.

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

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

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

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DAX: Microsoft Dynamics AX 2012 R3 is now available! Blog bot DAX Blogs 1 02.05.2014 23:00
atinkerersnotebook: Walkthrough & Tutorial Summary Blog bot DAX Blogs 1 09.09.2013 09:11
dynamics-ax: Kees Hertogh: The Benefits of a Model Driven Layered Architecture Blog bot DAX Blogs 0 30.03.2011 01:14
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:18.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.