08.05.2014, 19:42 | #21 |
Дмитрий Ерин
|
Н-да... R3 не видел, но с ваших слов представил себе подход так:
X++: public static AnyKibeniki TRAX() { Tibidox tibidox; ; return #Magic; } А по теме - книжки конечно полезны, но имхо, с паттернами эффективней знакомиться по исходникам какого-нибудь активно развивающегося OpenSource проекта, благо их сейчас в достатке, на любом языке и по любой тематике.
__________________
|
|
08.05.2014, 20:33 | #22 |
Banned
|
Паттерны проектирования
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 |
Участник
|
Цитата:
Сообщение от gl00mie
Не знаю, связано ли это с модой на функциональщину, но в том же чудо-модуле TRAX, который появился в R3, куча мест в коде написана так: по входным данным заполняется XML-ка, дергается поставляемая с модулем .NET-сборка - бульк! - на выходе получаем другую XML-ку, которая раскладывается по нужным таблицам. В итоге видим, что "что-то не срослось", как следствие, тариф не подобрался, перевозчик не определился, в общем, идите лесом. Чего ей надо, почему не подобралось ничего - поди догадайся. Ладно еще, если дело окажется в том, что во входной XML-ке значения енума передались русскими метками, а сборка ожидала увидеть там название элементов енума латиницей, такое можно раскопать "методом пристального взгляда", а в остальном - черный ящик...
|
|
09.05.2014, 02:03 | #24 |
Участник
|
Цитата:
Сообщение от Maximin
Они там не только "отметились", такое впечатление, что там пробежала орда сишарперов, которые под впечатлением от разрыва шаблона "not invented here", переписали кучу кода на C#-style. Проще говоря - наняли толпу людей с опытом C#, но совершенно без бэкграунда AX, которые попереписывали куски по своему пониманию.
Но я продолжаю зазывать людей с опытом АХ к нам в МС - так что если есть желающие - у нас двери открыты, позиции свободны. Милости просим. |
|
09.05.2014, 05:26 | #25 |
NavAx
|
Цитата:
Я даже больше скажу, для освоения аксапты, всегда нужно было хорошо разбираться в шаблонах. Тогда легче было понять что хотели сделать, что получилось в итоге и почему. Еще крайне полезно посмотреть другие EPR. Те же GP или Oracle. Чтобы понять, что пытались списывать и где возникли "ошибки перевода".
__________________
Isn't it nice when things just work? |
|
|
За это сообщение автора поблагодарили: Владимир Максимов (5). |
09.05.2014, 22:43 | #26 |
Участник
|
Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в Axapta?.
Знание паттернов - имеет смысл при разработке "с нуля" нового FrameWork. В рамках уже созданного FrameWork необходимо пользоваться уже готовыми паттернами этого самого FrameWork, а не выдумывать "самый правильный" способ решения задачи. Например, если мне надо создать в Axapta некий новый журнал, то я буду смотреть форму Tutorial_Journal, а вовсе не читать умные книжки по паттернам проектирования. Позволю самому себя себя же и процитировать Цитата:
Факт наличия базовых знаний вне контекста (знания) конкретного FrameWork приводит к очень печальным последствиям. А при наличии знания FrameWork наличие базовых знаний, лежащих в основе этого FrameWork, становится уже не обязательным.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
11.05.2014, 15:54 | #27 |
Участник
|
Цитата:
Сообщение от kashperuk
Ну, тут проблема только в том, чтобы публичный интерфейс движков красиво был документирован. Смотреть внутрь вовсе не обязательно (хотя, конкретно для TMS, код C# для движков идет в комплекте). А вот если вы интергируетесь с внешним сервис-провайдером типа UPS - вот тогда действительно черный ящик, и уповать придется только на задокументированный API. Но это - нормально..
Насчет модуля ТМS (TRAX) мне не до конца понятно зачем весь код TMS's "engines" выполнен на .Net, его с тем же успехом можно было реализовать на X++, может только хотели чтобы код выполнялся быстрее? Хотя это спорно.... Последний раз редактировалось hardcore; 11.05.2014 в 16:02. |
|
11.05.2014, 16:16 | #28 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
Если я правильно понимаю, это повтор темы Нужна ли теоретическая подготовка при программировании в Axapta?.
Знание паттернов - имеет смысл при разработке "с нуля" нового FrameWork. В рамках уже созданного FrameWork необходимо пользоваться уже готовыми паттернами этого самого FrameWork, а не выдумывать "самый правильный" способ решения задачи. Например, если мне надо создать в Axapta некий новый журнал, то я буду смотреть форму Tutorial_Journal, а вовсе не читать умные книжки по паттернам проектирования. Позволю самому себя себя же и процитировать Но вот что касается нового функционала я бы лишь согласился что в текущих реалиях, особено Российских, знания шаблонов для разработки понадобятся с вероятностью лишь 20% (пальцем в небо). Так как большинство проектов это кастомизация и адаптация под конечного клиента либо функционала на базе стандарта либо относительно небольших кусков принципиального нового функционала и интеграции, при таком подходе вроде бы все хорошо ложится на существующие Framework'и Ax. Цитата:
Сообщение от macklakov
Может не все разработчики знают умные названия, но вот используют постоянно. В "традиционной" аксапте шаблоны используются повсеместно. Builder - классы, construct методы, обертки с префиксом AX, десятки их.
Я даже больше скажу, для освоения аксапты, всегда нужно было хорошо разбираться в шаблонах. Об этом же и думали люди которые разрабатывали например SysOperation Framework или те кто придумывал механизмы интеграции с SSRS (правда не все там гладко получилось по моему мнению). Я думаю что знать шаблоны проектирования полезно (как сказал Цитата:
- Если вы разрабатывайте большой новый модуль, который планируете сами внедрять или может даже продавать, показательный пример тот же WAX/TRAX. - Либо вы разрабатывайте сквозной функционал через всю систему (например интеграция с какой-либо системой/компонентом, который может быть использован из любой части системы), показательный пример интеграция с SSRS. |
|
11.05.2014, 17:51 | #29 |
Участник
|
Также, на мой взгляд (это чистом мои мысли, я не претендую на какую-либо объективность), есть одна, более менее "филосовская" вещь, которая используется в Ах повсеместно, которая несколько мешает как усваивать многие из шаблонов проектирования так и применять их хоть сколько нибудь существенно - это "код инъекции". То есть мы постоянно пишем код который встраивается в чужой код (алгоритм) (в основном в стандард) и это именно стандартный Ах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 |
Banned
|
+1024
Добавлю что практически всегда у программиста AX есть несколько способов как именно кастомизировать уже имеющееся (красиво vs надежно vs быстро) но сам код никого не волнует. Работоспособность и время разработки единственные реальные критерии на практике. Очень долго еще умение понять что хочет постановщик задачи будет в десятки раз важнее чем строгий дизайн. Программист же если делает красиво то только для себя лично, для собственного удовлетворения. Сомневаюсь что то изменится в этом смысле. |
|
|
За это сообщение автора поблагодарили: Logger (3), NetBus (1). |
24.07.2014, 11:10 | #31 |
Участник
|
возможно кому-то пригодится:
Руководство MICROSOFT по проектированию архитектуры приложений" (2 издание) http://apparchguide.ms/Book |
|
|
За это сообщение автора поблагодарили: Logger (3), Krash (1), Stitch_MS (3), dech (1). |
24.07.2014, 12:40 | #32 |
Британский учённый
|
Там нужна регистрация. Вот прямая ссылка на скачивание.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
|
За это сообщение автора поблагодарили: Krash (1), AraraT® (3), S.Kuskov (1), dech (2), demoded (2). |
Теги |
ax2012, шаблон |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|