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

[Ruff]

Цитата:

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

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

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

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

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

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

[ax_mct]

Паттерны проектирования
http://www.rsdn.ru/summary/864.xml

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

Моя диссертация 2004 года на тему "Использование шаблонов проектирования Java в распределенных приложениях .NET"
http://www.mobiledevice.ru/panzer-so...k-traktor.aspx

[kashperuk]

Цитата:

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

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

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

[kashperuk]

Цитата:

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

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

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

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

[macklakov]

Цитата:

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

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

Может не все разработчики знают умные названия, но вот используют постоянно. В "традиционной" аксапте шаблоны используются повсеместно. Builder - классы, construct методы, обертки с префиксом AX, десятки их.
Я даже больше скажу, для освоения аксапты, всегда нужно было хорошо разбираться в шаблонах. Тогда легче было понять что хотели сделать, что получилось в итоге и почему.
Еще крайне полезно посмотреть другие EPR. Те же GP или Oracle. Чтобы понять, что пытались списывать и где возникли "ошибки перевода".

[Владимир Максимов]

Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в Axapta?.

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

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

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

Цитата:

Факт наличия базовых знаний вне контекста (знания) конкретного FrameWork приводит к очень печальным последствиям. А при наличии знания FrameWork наличие базовых знаний, лежащих в основе этого FrameWork, становится уже не обязательным.

[hardcore]

Цитата:

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

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

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

[hardcore]

Цитата:

Сообщение от Владимир Максимов

Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в 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.

[hardcore]

Также, на мой взгляд (это чистом мои мысли, я не претендую на какую-либо объективность), есть одна, более менее "филосовская" вещь, которая используется в Ах повсеместно, которая несколько мешает как усваивать многие из шаблонов проектирования так и применять их хоть сколько нибудь существенно - это "код инъекции". То есть мы постоянно пишем код который встраивается в чужой код (алгоритм) (в основном в стандард) и это именно стандартный Ахapta подход (такой "своеобразный паттерн" разработки) при этом компоненты системы на круг становятся более "связанными" (для реализации моей кастомизации/поведения которая базируется на стандартном функционале мне довольно часто надо знать как устроен этот функционал изнутри (знать именно алгоритм) (так как приходится вносить в него изменения, делать "код инъекции"). В противоположность же, в других ООП языках (C#, Java и т.д.), при разработке/проектировании (чего то более менее сложного нежели чем сайт с 15 страницами) хороший программист думает о своем коде как о компоненте или наборе компонентов, с которым будут работать другие компоненты, и он старается свести связь между компонентами к минимуму, выставляя на ружу из компонента контракт (набор интерфейсов) интуитивно объясняющий остальным разработчикам (да и себе самому на будущее) как нужно обращаться с его компонентами, в будущем этот контракт может дорабатываться. Вот здесь то паттерны (порождающие, структурные, поведенческие) используются на всю катушку, так как они и дают не малую долю той интуитивной понятности. И этап проектирования такого взаимодействия достаточно сложная задача, так как разработчик должен предугадать почти все варианты использования его кода другими компонентами (а точнее навязать через контракт, что с его компонентом можно работать только так, а не иначе). В Ах, при кастомизации для конченого клиента, такое тоже практикуется только в гораздо меньшей степени, думаю на пару порядков меньшей.
Так вот теперь как объяснить бенефит от использования этого хозяйства обычному разработчику в АХ если изначально он использует тот подход который предлагает система (т.к. он обычно кастомизирует стандарт) - "Да зачем что-то городить и так же понятно, залезаешь в мой класс создаешь нужные тебе поля, изменяешь поведение внутри моего класса как надо тебе и все чики пуки".
Ответ конечно есть (это не полный ответ, а лишь часть):
- Каждый такой класс становиться более сложным, нужно больше времени новому разработчику для изучения того, что этот класс делает, с учетом всех "если", без этого во многих ситуация, новому разработчику будет трудно его правильно использовать. Но так ведь построена система в целом и к этому все привыкли
- Это проблема с автоматическим тестированием, то есть чем больше таких изменений тем сложение класс покрыть юнит тестами. Но встает другой вопрос (риторический), а кто пишет юнит тесты в Ах (ну кроме МS и некоторых ISV) ?
P.S. Я не утверждаю что при разработки какой-либо сложной системы на Java или C# разработчики не используют подход такой как в АХ (если используют то очень ограничено, и при рефакторинге старого кода стараются снизить зависимость между компонентами), но все таки тенденция в разработке ПО в сторону слабой связанности между компонентами, в так называемой "Инверсии управления", и эта тенденция просто подталкивает обычных разработчиков к использованию все возможных паттернов.

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

[ax_mct]

+1024
Добавлю что практически всегда у программиста AX есть несколько способов как именно кастомизировать уже имеющееся (красиво vs надежно vs быстро) но сам код никого не волнует.
Работоспособность и время разработки единственные реальные критерии на практике.

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

[AlexeyS]

возможно кому-то пригодится:
Руководство MICROSOFT по проектированию архитектуры приложений" (2 издание)
http://apparchguide.ms/Book

[Link]

Там нужна регистрация. Вот прямая ссылка на скачивание.