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

[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

[gl00mie]

Цитата:

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

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

См. также Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL (не прошло и 5-и лет ):

Цитата:

Да, мы уже думали об этом. В частности, мы думали о том, чтобы генерировать из p-кода исходный код на C#, и нам это вполне под силу. И это дает нам возможность полностью отказаться от X++: давайте просто нажмем на кнопку и транслируем 98% имеющейся бизнес-логики в корректно работающий код на C#; затем мы можем посадить за работу армию программистов, и через месяц они доведут этот показатель до 100%, и тогда X++ уйдет в историю. Консалтинговые компании, ISV, компании, внедрившие Dynamics AX, - все те, кто ищут разработчиков для доработки приложения Dynamics AX, уже не будут говорить кандидатам: "...только вам придется еще выучить новый язык программирования, называемый X++", нет, вместо этого они смогут говорить: "вы будете работать с .NET в привычной среде разработки, это будет вкладом в вашу карьеру, все, чем вы будете заниматься у нас, вы затем сможете применить и в других компаниях". По-моему, это наилучший сценарий, который только можно вообразить.

[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. Но это - нормально..

[hardcore]

Цитата:

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

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

Ну в случае с .Net, если вдруг исходников для какой-либо сборки не найдется, собственно никто не мешает воспользоваться рефлектором (или дотпиком или еще чем-нибудь) и посмотреть как там оно устроено, если код там не путанный то все будет понятно (это обычная практика в .net если разработчику не хватает инфы по внешнему интерфейсу), конечно хуже чем иметь исходники ввиде проекта, но лучше чем ничего.
Насчет модуля ТМS (TRAX) мне не до конца понятно зачем весь код TMS's "engines" выполнен на .Net, его с тем же успехом можно было реализовать на X++, может только хотели чтобы код выполнялся быстрее? Хотя это спорно....

[kashperuk]

Цитата:

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

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

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

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