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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 08.05.2014, 19:42   #21  
Ruff is offline
Ruff
Дмитрий Ерин
Аватар для Ruff
1C
 
475 / 396 (14) ++++++
Регистрация: 18.09.2003
Адрес: Тула
Цитата:
Сообщение от gl00mie Посмотреть сообщение
в том же чудо-модуле TRAX, который появился в R3
Н-да... R3 не видел, но с ваших слов представил себе подход так:
X++:
public static AnyKibeniki TRAX()
{
    Tibidox  tibidox;
    ;
    return #Magic;
}
Можно даже предложить новый термин - "Стыдливые вычисления"

А по теме - книжки конечно полезны, но имхо, с паттернами эффективней знакомиться по исходникам какого-нибудь активно развивающегося OpenSource проекта, благо их сейчас в достатке, на любом языке и по любой тематике.
__________________
Старый 08.05.2014, 20:33   #22  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Паттерны проектирования
http://www.rsdn.ru/summary/864.xml

Паттерны ООП в метафорах
http://habrahabr.ru/post/136766/

Моя диссертация 2004 года на тему "Использование шаблонов проектирования Java в распределенных приложениях .NET"
http://www.mobiledevice.ru/panzer-so...k-traktor.aspx
За это сообщение автора поблагодарили: Ruff (1), Logger (3).
Старый 09.05.2014, 01:57   #23  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Не знаю, связано ли это с модой на функциональщину, но в том же чудо-модуле TRAX, который появился в R3, куча мест в коде написана так: по входным данным заполняется XML-ка, дергается поставляемая с модулем .NET-сборка - бульк! - на выходе получаем другую XML-ку, которая раскладывается по нужным таблицам. В итоге видим, что "что-то не срослось", как следствие, тариф не подобрался, перевозчик не определился, в общем, идите лесом. Чего ей надо, почему не подобралось ничего - поди догадайся. Ладно еще, если дело окажется в том, что во входной XML-ке значения енума передались русскими метками, а сборка ожидала увидеть там название элементов енума латиницей, такое можно раскопать "методом пристального взгляда", а в остальном - черный ящик...
Ну, тут проблема только в том, чтобы публичный интерфейс движков красиво был документирован. Смотреть внутрь вовсе не обязательно (хотя, конкретно для TMS, код C# для движков идет в комплекте). А вот если вы интергируетесь с внешним сервис-провайдером типа UPS - вот тогда действительно черный ящик, и уповать придется только на задокументированный API. Но это - нормально..
Старый 09.05.2014, 02:03   #24  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от Maximin Посмотреть сообщение
Они там не только "отметились", такое впечатление, что там пробежала орда сишарперов, которые под впечатлением от разрыва шаблона "not invented here", переписали кучу кода на C#-style. Проще говоря - наняли толпу людей с опытом C#, но совершенно без бэкграунда AX, которые попереписывали куски по своему пониманию.
Можно долго спорить, хорошо это или плохо, но Майкрософт всегда нанимает людей с учетом стратегии "One Microsoft", соответственно только-Х++-чики нам не подходят, многие из тех, кого я рекомендовал попробовать получить у нас работу, валились на простых вопросах проектирования или кодирования не Х++ задач.

Но я продолжаю зазывать людей с опытом АХ к нам в МС - так что если есть желающие - у нас двери открыты, позиции свободны. Милости просим.
Старый 09.05.2014, 05:26   #25  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от db Посмотреть сообщение
К шаблонам проектирования все относятся по разному - кто то молится на них, кто то на дух не переваривает, ну а основная масса DAX разработчиков про них просто не знает
Может не все разработчики знают умные названия, но вот используют постоянно. В "традиционной" аксапте шаблоны используются повсеместно. Builder - классы, construct методы, обертки с префиксом AX, десятки их.
Я даже больше скажу, для освоения аксапты, всегда нужно было хорошо разбираться в шаблонах. Тогда легче было понять что хотели сделать, что получилось в итоге и почему.
Еще крайне полезно посмотреть другие EPR. Те же GP или Oracle. Чтобы понять, что пытались списывать и где возникли "ошибки перевода".
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: Владимир Максимов (5).
Старый 09.05.2014, 22:43   #26  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в Axapta?.

Знание паттернов - имеет смысл при разработке "с нуля" нового FrameWork. В рамках уже созданного FrameWork необходимо пользоваться уже готовыми паттернами этого самого FrameWork, а не выдумывать "самый правильный" способ решения задачи.

Например, если мне надо создать в Axapta некий новый журнал, то я буду смотреть форму Tutorial_Journal, а вовсе не читать умные книжки по паттернам проектирования.

Позволю самому себя себя же и процитировать

Цитата:
Факт наличия базовых знаний вне контекста (знания) конкретного FrameWork приводит к очень печальным последствиям. А при наличии знания FrameWork наличие базовых знаний, лежащих в основе этого FrameWork, становится уже не обязательным.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 11.05.2014, 15:54   #27  
hardcore is offline
hardcore
Участник
 
16 / 32 (2) +++
Регистрация: 02.11.2006
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Ну, тут проблема только в том, чтобы публичный интерфейс движков красиво был документирован. Смотреть внутрь вовсе не обязательно (хотя, конкретно для TMS, код C# для движков идет в комплекте). А вот если вы интергируетесь с внешним сервис-провайдером типа UPS - вот тогда действительно черный ящик, и уповать придется только на задокументированный API. Но это - нормально..
Ну в случае с .Net, если вдруг исходников для какой-либо сборки не найдется, собственно никто не мешает воспользоваться рефлектором (или дотпиком или еще чем-нибудь) и посмотреть как там оно устроено, если код там не путанный то все будет понятно (это обычная практика в .net если разработчику не хватает инфы по внешнему интерфейсу), конечно хуже чем иметь исходники ввиде проекта, но лучше чем ничего.
Насчет модуля ТМS (TRAX) мне не до конца понятно зачем весь код TMS's "engines" выполнен на .Net, его с тем же успехом можно было реализовать на X++, может только хотели чтобы код выполнялся быстрее? Хотя это спорно....

Последний раз редактировалось hardcore; 11.05.2014 в 16:02.
Старый 11.05.2014, 16:16   #28  
hardcore is offline
hardcore
Участник
 
16 / 32 (2) +++
Регистрация: 02.11.2006
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в Axapta?.

Знание паттернов - имеет смысл при разработке "с нуля" нового FrameWork. В рамках уже созданного FrameWork необходимо пользоваться уже готовыми паттернами этого самого FrameWork, а не выдумывать "самый правильный" способ решения задачи.

Например, если мне надо создать в Axapta некий новый журнал, то я буду смотреть форму Tutorial_Journal, а вовсе не читать умные книжки по паттернам проектирования.

Позволю самому себя себя же и процитировать
Да какая-то часть шаблонов уже давно была в Ах и людям для работы не нужно было знать например, что construct это тоже шаблон. Я думаю даже сейчас что с выходом 2012 многие люди которые делают отчеты, либо не задумываются что Framework построен по принципу MVC паттерна (хоть и с отступлениями), либо знают что по MVC, но не на 100% представляют как реально этот паттерн устроен и недостаток этих знаний не мешает им строить хорошие отчеты.
Но вот что касается нового функционала я бы лишь согласился что в текущих реалиях, особено Российских, знания шаблонов для разработки понадобятся с вероятностью лишь 20% (пальцем в небо). Так как большинство проектов это кастомизация и адаптация под конечного клиента либо функционала на базе стандарта либо относительно небольших кусков принципиального нового функционала и интеграции, при таком подходе вроде бы все хорошо ложится на существующие Framework'и Ax.

Цитата:
Сообщение от macklakov Посмотреть сообщение
Может не все разработчики знают умные названия, но вот используют постоянно. В "традиционной" аксапте шаблоны используются повсеместно. Builder - классы, construct методы, обертки с префиксом AX, десятки их.
Я даже больше скажу, для освоения аксапты, всегда нужно было хорошо разбираться в шаблонах.
И наверно совсем другое дело если вы пишите не конечную кастомизацию, а участвуете в разработке какого-либо решения например если вы ISV, или если вы учавствуете в разработке стандарта. Вот тут-то надо очень хорошо думать об архитектуре системы/модуля и о том как и каким образом ваш код будет использоваться другими разработчиками (в этом как раз могут помочь шаблоны проектирования). Так как в таком случае вы разрабатывайте функционал не только для потенциального клиента, и его будет использовать не только условный разработчик "Вася" который сидит за соседним столом, но и для многих других, которые будут смотреть на это код через год другой и думать как его использовать в своих кастомизациях для клиентов.
Об этом же и думали люди которые разрабатывали например SysOperation Framework или те кто придумывал механизмы интеграции с SSRS (правда не все там гладко получилось по моему мнению).
Я думаю что знать шаблоны проектирования полезно (как сказал
Цитата:
Сообщение от macklakov Посмотреть сообщение
Тогда легче было понять что хотели сделать, что получилось в итоге и почему
) для общего развития, но для текущей версии Ах, я думаю, обычному разработчику сильно заморачиваться над шаблонами проектирования надо в 2 случаях:
- Если вы разрабатывайте большой новый модуль, который планируете сами внедрять или может даже продавать, показательный пример тот же WAX/TRAX.
- Либо вы разрабатывайте сквозной функционал через всю систему (например интеграция с какой-либо системой/компонентом, который может быть использован из любой части системы), показательный пример интеграция с SSRS.
Старый 11.05.2014, 17:51   #29  
hardcore is offline
hardcore
Участник
 
16 / 32 (2) +++
Регистрация: 02.11.2006
Также, на мой взгляд (это чистом мои мысли, я не претендую на какую-либо объективность), есть одна, более менее "филосовская" вещь, которая используется в Ах повсеместно, которая несколько мешает как усваивать многие из шаблонов проектирования так и применять их хоть сколько нибудь существенно - это "код инъекции". То есть мы постоянно пишем код который встраивается в чужой код (алгоритм) (в основном в стандард) и это именно стандартный Ахapta подход (такой "своеобразный паттерн" разработки) при этом компоненты системы на круг становятся более "связанными" (для реализации моей кастомизации/поведения которая базируется на стандартном функционале мне довольно часто надо знать как устроен этот функционал изнутри (знать именно алгоритм) (так как приходится вносить в него изменения, делать "код инъекции"). В противоположность же, в других ООП языках (C#, Java и т.д.), при разработке/проектировании (чего то более менее сложного нежели чем сайт с 15 страницами) хороший программист думает о своем коде как о компоненте или наборе компонентов, с которым будут работать другие компоненты, и он старается свести связь между компонентами к минимуму, выставляя на ружу из компонента контракт (набор интерфейсов) интуитивно объясняющий остальным разработчикам (да и себе самому на будущее) как нужно обращаться с его компонентами, в будущем этот контракт может дорабатываться. Вот здесь то паттерны (порождающие, структурные, поведенческие) используются на всю катушку, так как они и дают не малую долю той интуитивной понятности. И этап проектирования такого взаимодействия достаточно сложная задача, так как разработчик должен предугадать почти все варианты использования его кода другими компонентами (а точнее навязать через контракт, что с его компонентом можно работать только так, а не иначе). В Ах, при кастомизации для конченого клиента, такое тоже практикуется только в гораздо меньшей степени, думаю на пару порядков меньшей.
Так вот теперь как объяснить бенефит от использования этого хозяйства обычному разработчику в АХ если изначально он использует тот подход который предлагает система (т.к. он обычно кастомизирует стандарт) - "Да зачем что-то городить и так же понятно, залезаешь в мой класс создаешь нужные тебе поля, изменяешь поведение внутри моего класса как надо тебе и все чики пуки".
Ответ конечно есть (это не полный ответ, а лишь часть):
- Каждый такой класс становиться более сложным, нужно больше времени новому разработчику для изучения того, что этот класс делает, с учетом всех "если", без этого во многих ситуация, новому разработчику будет трудно его правильно использовать. Но так ведь построена система в целом и к этому все привыкли
- Это проблема с автоматическим тестированием, то есть чем больше таких изменений тем сложение класс покрыть юнит тестами. Но встает другой вопрос (риторический), а кто пишет юнит тесты в Ах (ну кроме МS и некоторых ISV) ?
P.S. Я не утверждаю что при разработки какой-либо сложной системы на Java или C# разработчики не используют подход такой как в АХ (если используют то очень ограничено, и при рефакторинге старого кода стараются снизить зависимость между компонентами), но все таки тенденция в разработке ПО в сторону слабой связанности между компонентами, в так называемой "Инверсии управления", и эта тенденция просто подталкивает обычных разработчиков к использованию все возможных паттернов.

Думаю что Ах встанет крепко на эти рельсы через пару версий

Последний раз редактировалось hardcore; 11.05.2014 в 17:59.
За это сообщение автора поблагодарили: gudzon (1), ax_mct (4), gl00mie (2).
Старый 12.05.2014, 22:50   #30  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
+1024
Добавлю что практически всегда у программиста AX есть несколько способов как именно кастомизировать уже имеющееся (красиво vs надежно vs быстро) но сам код никого не волнует.
Работоспособность и время разработки единственные реальные критерии на практике.

Очень долго еще умение понять что хочет постановщик задачи будет в десятки раз важнее чем строгий дизайн. Программист же если делает красиво то только для себя лично, для собственного удовлетворения. Сомневаюсь что то изменится в этом смысле.
За это сообщение автора поблагодарили: Logger (3), NetBus (1).
Старый 24.07.2014, 11:10   #31  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
возможно кому-то пригодится:
Руководство MICROSOFT по проектированию архитектуры приложений" (2 издание)
http://apparchguide.ms/Book
За это сообщение автора поблагодарили: Logger (3), Krash (1), Stitch_MS (3), dech (1).
Старый 24.07.2014, 12:40   #32  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 513 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Там нужна регистрация. Вот прямая ссылка на скачивание.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
За это сообщение автора поблагодарили: Krash (1), AraraT® (3), S.Kuskov (1), dech (2), demoded (2).
Теги
ax2012, шаблон

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DAX 2012 шаблоны ГФО cM3 DAX: Функционал 9 23.10.2014 00:50
DAX: How to gain additional value from the Microsoft application platform with Microsoft Dynamics AX 2012 R2 Blog bot DAX Blogs 3 21.06.2013 15:16
amer-ax: It was a great day! Blog bot DAX Blogs 3 29.12.2012 01:02
DAX: Official Dynamics AX 2012 R2 Content (update) - Where is it, and how can you find out about updates? Blog bot DAX Blogs 0 03.12.2012 11:11
dynamicsaxtraining: Purchase Blog bot DAX Blogs 0 11.03.2012 05:25
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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