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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.02.2011, 19:37   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
для чего нужны эти модели? только для того, чтобы можно было генерить лицензии сторонним разработчикам?
Я так понял, чтобы группировать связанные объекты приложения в рамках одного слоя. Ведь в 2012-й было много сделано для устранения проблемы идентификаторов объектов и для возможности более "гранулярного" изменения объектов приложения (добавление кнопок на форму без перетаскивания всей формы на вышележащий слой - это просто фантастика! ). Целью всего этого, как я понимаю, было дать возможность клиентам относительно безболезненно совмещать на одном слое несколько различных решений сторонних разработчиков.
Механизм, позволяющий одним компаниям создать свое законченное решение для определенной задачи, упаковать его в модель и защитить лицензионным ключом, а другим компаниям - очень легко интегрировать это решение в существующую систему, видимо, должен подстегнуть развитие рынка "частных" решений на базе Аксапты и сделать ее более интересной для компаний, внедряющих ее у себя. Тем более заманчиво все это выглядит на фоне появления нового подхода к кастомизации приложения на основе обработки событий. Для тех, кто пишет на C#, это, пожалуй, уже стало обыденностью, но в коде приложения Аксапты видеть, к примеру, тот же код сбора конфликтов обновления приложения в проекты для меня лично было сродни встречи с инопланетянами Там реализован один общий движок, а выявление различных типов конфликтов и создание проектов осуществляется дополнительными классами, которые просто "подписываются" на определенные события, генерируемые этим движком. И сам движок ничего не знает об этих классах, кроме того, что они реализуют определенный интерфейс обработчиков событий. По-моему, в стандартном приложении такой подход раньше нигде не использовался, в то же время он позволяет невероятно гибко модифицировать работу приложения, не осуществляя "хирургического вмешательства" в него.
Теги
ax2012

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
mfp: Seeing is believing - AX2012 Creating an ISV Model Blog bot DAX Blogs 0 04.02.2011 19:11
Channel9: AX2012 - X++ Editor Blog bot DAX Blogs 0 03.02.2011 18:11
Channel9: AX2012 - Type Hierarchies Blog bot DAX Blogs 0 02.02.2011 14:11
channel9: Michael Fruergaard Pontoppidan – Model driven development in Dynamics AX Blog bot DAX Blogs 0 28.10.2006 23:29
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:47.