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

[Pustik]

Цитата:

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

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

- "Я красиво сел задницей на гвоздь, и установил его туда куда нужно",
- "А я, обычным молотком прибил этот гвоздь".

[ax_mct]

Цитата:

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

- "Я красиво сел задницей на гвоздь, и установил его туда куда нужно",
- "А я, обычным молотком прибил этот гвоздь".

Простота тоже не всегда вариант, особенно в руках некоторых индусов не понимающих ООП в принципе и тем более шаблоны проектирования.
Но когда в чужом монастыре пытаются навести свой ужасный порядок начиная с наименования переменных и не имея понятия об уставе монастыря (best practices по всем темам) чувствуешь не просто раздражение а праведный гнев

Мне их тоже однако жаль, быть программистом AX это быть золотарем, не для чистюль То есть свалка и грязь чаще всего и никакие шаблоны это не разгребут

[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

[macklakov]

Цитата:

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

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

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

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

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

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

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

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

Цитата:

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

[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]

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