Channel9: AX2012 - Creating an ISV Model

[Blog bot]

Источник: http://channel9.msdn.com/Blogs/mfp/A...g-an-ISV-Model
==============

This recording shows how an ISV can create a solution in AX 2012, including:

• How to create a new model in AX.
• Why element IDs are not a concern anymore.
• Protecting the solution using a licensing scheme.
• Generating a signed model file for deployment.
• How to generate licenses for customers.

THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.



Источник: http://channel9.msdn.com/Blogs/mfp/A...g-an-ISV-Model

[mazzy]

сижу. смотрю. втыкаю.

похоже чего-то главного не догоняю.
для чего нужны эти модели? только для того, чтобы можно было генерить лицензии сторонним разработчикам?
чего я не понимаю?

[gl00mie]

Цитата:

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

для чего нужны эти модели? только для того, чтобы можно было генерить лицензии сторонним разработчикам?

Я так понял, чтобы группировать связанные объекты приложения в рамках одного слоя. Ведь в 2012-й было много сделано для устранения проблемы идентификаторов объектов и для возможности более "гранулярного" изменения объектов приложения (добавление кнопок на форму без перетаскивания всей формы на вышележащий слой - это просто фантастика! ). Целью всего этого, как я понимаю, было дать возможность клиентам относительно безболезненно совмещать на одном слое несколько различных решений сторонних разработчиков.
Механизм, позволяющий одним компаниям создать свое законченное решение для определенной задачи, упаковать его в модель и защитить лицензионным ключом, а другим компаниям - очень легко интегрировать это решение в существующую систему, видимо, должен подстегнуть развитие рынка "частных" решений на базе Аксапты и сделать ее более интересной для компаний, внедряющих ее у себя. Тем более заманчиво все это выглядит на фоне появления нового подхода к кастомизации приложения на основе обработки событий. Для тех, кто пишет на C#, это, пожалуй, уже стало обыденностью, но в коде приложения Аксапты видеть, к примеру, тот же код сбора конфликтов обновления приложения в проекты для меня лично было сродни встречи с инопланетянами Там реализован один общий движок, а выявление различных типов конфликтов и создание проектов осуществляется дополнительными классами, которые просто "подписываются" на определенные события, генерируемые этим движком. И сам движок ничего не знает об этих классах, кроме того, что они реализуют определенный интерфейс обработчиков событий. По-моему, в стандартном приложении такой подход раньше нигде не использовался, в то же время он позволяет невероятно гибко модифицировать работу приложения, не осуществляя "хирургического вмешательства" в него.

[kashperuk]

На самом деле, я тоже не до конца понимаю, зачем они нужны были..
Но одно красивейшее использование - это выделение DEL_ элементов в отдельную модель с последующим удалением этой модели. Намного удобнее работать с приложением, учитывая сколько накопилось DEL_ барахла.

[konopello]

Цитата:

на основе обработки событий

все это давно имеется в C#, Java, ABAP но до сих пор не было в X++. Для тех кто не очень знаком с данной технологией поясню эту технологию на не большом примере:

Создаем экземпляр Класса "Транспортное средство", данный класс умеет выкрикивать Event, ну к примеру "Я изменился", "Я сохраняюсь".

В системе имеется экземпляры классов "Менеджер1", "Менеджер2", "Менеджер3", который в свою очередь имеют специфические методы, ну к примеру "Когда транспортное средство изменилось" и "Когда транспортное средство сохраняется".

Все это были исходные данные.

В определенной точке кода методы класса "Менеджер" должны быть связанны с событиями класса "Транспортное средство", ну что то типа:
- "Менеджер"."Когда транспортное средство изменилось" связываем с "Транспортное средство"."Я изменился"
- "Менеджер"."Когда транспортное средство сохраняется" связываем с "Транспортное средство"."Я сохраняюсь"

Ну и дальше как это работает:
Когда происходит изменение экземпляра "Транспортное средство", этот экземпляр выкрикивает событие "Я изменился". Автоматически после выкрикивания события все классы "Менеджеров" подписанные на это событие вызывают свои методы, ну и к примеру:

"Транспортное средство"."Я изменился"

- "Менеджер1"."Когда транспортное средство изменилось"
- "Менеджер2"."Когда транспортное средство изменилось"
- "Менеджер3"."Когда транспортное средство изменилось"

[gl00mie]

Цитата:

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

все это давно имеется в C#, Java, ABAP но до сих пор не было в X++.

Скажем так, шаблон publish/subscribe не является "фичей" какого-то языка, потому что почти на любом языке достаточно легко реализуем (в т.ч. в Х++). Тут дело именно в том, что он не использовался в стандартном приложении Аксапты - за исключением, разве что, синхронизации работы нескольких АОСов в кластере, но, к счастью, в этом плане происходят заметные изменения.

[konopello]

Цитата:

Скажем так, шаблон publish/subscribe не является "фичей" какого-то языка, потому что почти на любом языке достаточно легко реализуем (в т.ч. в Х++). Тут дело именно в том, что он не использовался в стандартном приложении Аксапты - за исключением, разве что, синхронизации работы нескольких АОСов в кластере, но, к счастью, в этом плане происходят заметные изменения.

Могу только добавить, не знал про все это и прекрасно работал в AX, связался с ABAP и теперь без этого просто не могу : )