DAX 2012 и шаблоны проектирования

[db]

К шаблонам проектирования все относятся по разному - кто то молится на них, кто то на дух не переваривает, ну а основная масса DAX разработчиков про них просто не знает

Выскажу такое мнение - если вы разработчик DAX 2012 то узнать про шаблоны требуется в обязательном порядке, а следующие две книги

Приемы объектно-ориентированного проектирования. Паттерны проектирования
Архитектура корпоративных программных приложений

обязательны к изучению. Просто потому что те, кто проектировал DAX 2012 про шаблоны знали и применяли. Как применяли и каковы результаты применения уже другой вопрос. Но вопросов "а что это за хрень?", "что они курили?", "#####%%%%%ьььь????" и прочих подобных после изучения станет в разы меньше. Просто вы станете "видеть" эти шаблоны в системе, сможете сравнить то что получилось в DAX с тем что пишут в книжках/интернетах, сможете агрументированно высказывать своё мнение.

Книг по этой тематике немало, но ИМХО разработчикам DAX начинать надо с тех что я написал.

[NetBus]

Цитата:

Просто потому что те, кто проектировал DAX 2012 про шаблоны знали и применяли.

а те кто проектировал DAX 2009? знали? применяли?

[S.Kuskov]

Цитата:

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

а те кто проектировал DAX 2009? знали? применяли?

Если сравнивать с 2012 то в DAX 2009 вообще ничего нового не проектировали. Проект взяли из AX 4.0 а тот в свою очередь из 3.0 и т.д.

[gl00mie]

Цитата:

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

а те кто проектировал DAX 2009? знали? применяли?

Я лично не видел 4.0, так что мое мнение может быть ошибочным, но, к примеру, в 2009-й появились примеры использования шаблона listener/subscriber, которого даже рядом не было в приложении 3.0, широко стал применяться шаблон "стратегия", ему даже посвятили отдельную тему в MSDN. Вообще, по-моему, в 2009-й отметились люди из C#, которые попытались "программировать с использованием языка, а не на языке" X++.

[AlexeyS]

и похоже, придется вплотную заняться C#, так как есть подозрение, что через пару лет X++ в Аксапте может отойти на второй план.

[NetBus]

я так думаю что X++ в стратегии Microsoft уже умер =))) т е "живой труп" или "хромая утка" используя политическую аналогию

[AlexeyS]

Цитата:

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

я так думаю что X++ в стратегии Microsoft уже умер =))) т е "живой труп" или "хромая утка" используя политическую аналогию

Согласен. Отказ от X++ дает много преимуществ для MS:
Во-первых, C# программистов больше и поэтому дешевле, поэтому корпоративным заказчикам будет проще закрыть вакансии при внедрении и поддержке. Это дает больше возможностей для расширения рынка для MS
Во-вторых, X++ уже сейчас используется только для бизнес-логики и может компилироваться в CIL
И в третьих, поддержка еще одного языка требует дополнительных ресурсов
IMHO

[Maximin]

Цитата:

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

Вообще, по-моему, в 2009-й отметились люди из C#, которые попытались "программировать с использованием языка, а не на языке" X++.

Они там не только "отметились", такое впечатление, что там пробежала орда сишарперов, которые под впечатлением от разрыва шаблона "not invented here", переписали кучу кода на C#-style. Проще говоря - наняли толпу людей с опытом C#, но совершенно без бэкграунда AX, которые попереписывали куски по своему пониманию. Всё бы ничего, но существующие инструментальные средства разработки в AX совершенно не готовы (да хотя бы те же перекрестные ссылки, не говоря уже о рудиментарности средств работы со сложными иерархиями классов) к существующей теперь структуре API. Как они со всем этим управлялись - неведомо. Впрочем, скрипя зубами, это можно пережить. Оттенков вкуса от новой версии добавляют еще и отчеты в SSRS (особенно приятно сливать новые версии отчетов)...
Да, если человек все время варился в кухне AX, то отставание от существующих подходов к разработке, определенно, накапливается. И книги из первого поста позволят наверстать упущенное за последние лет 5-10 (примерно к тем временам, если не более ранним, относится появление концепции "шаблонов проектирования").Другое дело, что вменяемый разработчик бОльшую часть этих шаблонов и сам применяет, просто не давая им конкретного названия. Они - суть просто готовые "рецепты" со своими областями применимости.
Еще далеко шагнуло версионирование (появление GIT),
По ходу написания пришла мысль. Будет забавно, если в Аксапту лет через 5-10 докатится мода на "ленивые вычисления" или функциональщину... Интересно, во что это выльется?

[gl00mie]

Цитата:

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

Будет забавно, если в Аксапту лет через 5-10 докатится мода на "ленивые вычисления" или функциональщину... Интересно, во что это выльется?

Не знаю, связано ли это с модой на функциональщину, но в том же чудо-модуле TRAX, который появился в R3, куча мест в коде написана так: по входным данным заполняется XML-ка, дергается поставляемая с модулем .NET-сборка - бульк! - на выходе получаем другую XML-ку, которая раскладывается по нужным таблицам. В итоге видим, что "что-то не срослось", как следствие, тариф не подобрался, перевозчик не определился, в общем, идите лесом. Чего ей надо, почему не подобралось ничего - поди догадайся. Ладно еще, если дело окажется в том, что во входной XML-ке значения енума передались русскими метками, а сборка ожидала увидеть там название элементов енума латиницей, такое можно раскопать "методом пристального взгляда", а в остальном - черный ящик...

[Ruff]

Цитата:

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

в том же чудо-модуле TRAX, который появился в R3

Н-да... R3 не видел, но с ваших слов представил себе подход так:

public static AnyKibeniki TRAX()
{
    Tibidox  tibidox;
    ;
    return #Magic;
}

Можно даже предложить новый термин - "Стыдливые вычисления"

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

[kashperuk]

Цитата:

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

Не знаю, связано ли это с модой на функциональщину, но в том же чудо-модуле TRAX, который появился в R3, куча мест в коде написана так: по входным данным заполняется XML-ка, дергается поставляемая с модулем .NET-сборка - бульк! - на выходе получаем другую XML-ку, которая раскладывается по нужным таблицам. В итоге видим, что "что-то не срослось", как следствие, тариф не подобрался, перевозчик не определился, в общем, идите лесом. Чего ей надо, почему не подобралось ничего - поди догадайся. Ладно еще, если дело окажется в том, что во входной XML-ке значения енума передались русскими метками, а сборка ожидала увидеть там название элементов енума латиницей, такое можно раскопать "методом пристального взгляда", а в остальном - черный ящик...

Ну, тут проблема только в том, чтобы публичный интерфейс движков красиво был документирован. Смотреть внутрь вовсе не обязательно (хотя, конкретно для TMS, код C# для движков идет в комплекте). А вот если вы интергируетесь с внешним сервис-провайдером типа UPS - вот тогда действительно черный ящик, и уповать придется только на задокументированный API. Но это - нормально..

[kashperuk]

Цитата:

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

Они там не только "отметились", такое впечатление, что там пробежала орда сишарперов, которые под впечатлением от разрыва шаблона "not invented here", переписали кучу кода на C#-style. Проще говоря - наняли толпу людей с опытом C#, но совершенно без бэкграунда AX, которые попереписывали куски по своему пониманию.

Можно долго спорить, хорошо это или плохо, но Майкрософт всегда нанимает людей с учетом стратегии "One Microsoft", соответственно только-Х++-чики нам не подходят, многие из тех, кого я рекомендовал попробовать получить у нас работу, валились на простых вопросах проектирования или кодирования не Х++ задач.

Но я продолжаю зазывать людей с опытом АХ к нам в МС - так что если есть желающие - у нас двери открыты, позиции свободны. Милости просим.

[dech]

До AX2012 RecId не использовался как полноценный ключ.
Плюсом для АХ4 и выше стало появление Unit Testing.

[fed]

По моим ощущениям, у опытного разработчика (на любом языке) на изучение X++ уходит порядка 2-3 недель. На изучение среды исполнения (в общем - как решать задачи по формированию форм, работе с контроллами, отчетами и тп) уходит порядка 6-8 месяцев. На изучение собственно прикладного ядра до приличного уровня - года 3-4-5 (как повезет). Перевод на C# позволит сэкономить аж 2-3 недели из 3-4-5 лет. Большой прогресс. Безусловно оправдяет слом всей среды...

[AlexeyS]

Изучить X++ легче, чем C#, это верно, только проблема не в этом, а в том, что X++ это довольно узкая ниша и грозит стать еще уже.
Поэтому для программиста нужен существенный довод, чтобы с широко распространенного C# перейти на более простой и менее востребованный, ведь вернуться обратно будет сложнее.
Тут ситуация как с Delphi - есть проекты, есть вакансии, но если ты уже опытный программист на другом языке, то на Delphi вряд-ли пойдешь, так как в дальней перспективе - неперспективно.
Поэтому постепенно перейдем на C# в течение нескольких лет, ничего страшного.

[fed]

Цитата:

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

Изучить X++ легче, чем C#, это верно, только проблема не в этом, а в том, что X++ это довольно узкая ниша и грозит стать еще уже.

Поэтому постепенно перейдем на C# в течение нескольких лет, ничего страшного.

Вот когда явшиков на работу берут, там почти всегда указывают кого ищут - server side developer, swingиста, JMEшника и тп. Аналогично для C# указывают кого ищут - server side или WPF. Боюсь, что с навыком C# AX у тебя в С# server-side или в C# WPF шансов найти работу будет намного меньше чем у явщика с навыками server side или Swing соответственно. То есть - технология первична, язык - вторичен.
Если продолжать пример с Delphi - была еще такая среда разработки C++ Builder, фактически Delphi сделанный на языке C++. И этим самым программистам на C++ Builder сейчас найти нормальную работу не намного легче чем Дельфистам. Потому что чтобы с VCL переучиться на MFC+ATL, сил нужно потратить почти столько же сколько на изучение C++ +MFC+ATL с ноля (при условии наличия общего программистского опыта конечно).

[Link]

Да-да, теперь можно прочесть книгу С# за 21 день и идти работать АХ разработчиком, смишно. В любой среде разработки главное не язык, а знание технологий и непосредственное опыт. В Акспте требуется не просто кодить, а понимать архитектуру, функционал, бизнес процессы и еще много много других вещей которые к тому же еще и между версиями могут очень отличаться. Так что армия дотнетчиков это все сказки. Мне кажется единственная цель с которой МС переводит АХ на дотнет это более гибкие возможности интеграции с другими компонентами, продуктами и системами. Все остальное имхо этого не стоит.

[fed]

Цитата:

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

Так что армия дотнетчиков это все сказки. Мне кажется единственная цель с которой МС переводит АХ на дотнет это более гибкие возможности интеграции с другими компонентами, продуктами и системами. Все остальное имхо этого не стоит.

На самом деле - то что для нас сказка ("Да вы разработчиков на любом C# форуме наймете за 50000 в месяц"), для сейлов - важный sales point при работе с клиентским Айтишником. Ни о каких интеграциях тут и речи не идет. Просто в любом продукте должны быть "бусы для дикарей", которые облегчают его продажу тем сотрудникам клиента, которые совсем не в теме и задают не те вопросы. На мой взгляд - и перевод на C# и workflow и интеграция с Analysis Services - из этой оперы....

[dech]

Цитата:

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

Тут ситуация как с Delphi - есть проекты, есть вакансии, но если ты уже опытный программист на другом языке, то на Delphi вряд-ли пойдешь, так как в дальней перспективе - неперспективно.

Я бы поспорил. Мне до сих пор на фрилансе приходят предложения по Delphi. Между прочим Skype тоже написан на Delphi, платежная система Апельсин, а также различные улучшалки производительности Windows от фирмы Auslogics Software. Так что здесь как посмотреть...

[ax_mct]

На последнем проекте был хороший программист из C#. Написал с нуля вывод во внутренние отчеты AX. Типа полное разделение уровня дизайна и кода, ни строчки кода в AOT/Report. Красиво, я оценил, но мне хотелось его придушить.