AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.06.2017, 19:58   #101  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет.
Ок, Гугл!! ))
Я все время испытывал ужасный дискомфорт, когда нарушал это правило ВР.
И мне было неудобно перед теми программистами, кто знает ВР и может меня упрекнуть в нарушении этого правила.
И тут... тадам.
SysOperationServiceController
метод
new
!!!
Улыбаемся и машем!
Если кто-то скажет, что это неправильный класс и так нельзя делать, то даже не знаю что и подумать....
-----------------
На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.
В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.
Я не могу себе даже представить такую ситуацию, в которой необходим чистый класс, который на входе не принимает никаких параметров вообще.
Возможно, я ошибаюсь. Можете привести хоть один пример класса, в котором не нужны параметры?...
---------
Может быть выделить это обсуждение в отдельную тему? А то офтопик получается...

Последний раз редактировалось ta_and; 07.06.2017 в 20:10.
За это сообщение автора поблагодарили: Михаил Андреев (5), Pustik (2).
Старый 08.06.2017, 15:16   #102  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.
Почему не AnyType

Цитата:
В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.
Вероятно имеется ввиду, что надо делать protected new и инициализировать параметрами фабричными методами. Чтобы было

Circle::createByCenterAndRadius(p1, r1);
Circle::createByTwoPonts(p1, p2)

А не new Circle(null, 0, p1, p2)

Цитата:
Я не могу себе даже представить такую ситуацию, в которой необходим чистый класс, который на входе не принимает никаких параметров вообще.
Возможно, я ошибаюсь. Можете привести хоть один пример класса, в котором не нужны параметры?...
Какой-нибудь билдер, которому проще надиктовать параметры последовательно.
Старый 08.06.2017, 15:52   #103  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
А можно поинтересоваться, как вы создаете окружность по двум точкам? : )
Старый 08.06.2017, 16:37   #104  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от EVGL Посмотреть сообщение
А можно поинтересоваться, как вы создаете окружность по двум точкам? : )
Например окружность минимального радиуса, проходящая через заданные точки.
Старый 08.06.2017, 17:54   #105  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
А можно поинтересоваться, как вы создаете окружность по двум точкам? : )
или окружность бесконечного радиуса, проходящая через заданные точки.
__________________
полезное на axForum, github, vk, coub.
Старый 09.06.2017, 15:09   #106  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от belugin Посмотреть сообщение
Почему не AnyType
Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
Аргс используется как буфер обмена повсеместно, во всей системе, формы, main, джобы...Это де-факто - параметр по умолчанию. Почему бы его не использовать и для инициализации классов?
Старый 09.06.2017, 15:25   #107  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
А аргс конечно типизирован только там может быть незаполнено что угодно для конкретного класса.

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI. Он содержит UI специфичные параметры, а остальное фактически так же нетипизировано как AnyType
Старый 09.06.2017, 15:36   #108  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI.
да. права, метка и подсказка на разных языках, параметр где запускать... и прочие "специфичные" UI параметры.
и не говори, очень жаль, что "используется не повсеместно".
__________________
полезное на axForum, github, vk, coub.
Старый 10.06.2017, 05:23   #109  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от belugin Посмотреть сообщение
только там может быть незаполнено
То, что не заполнено, как раз не проблема.
Это дело уже инициализируемого объекта - проверить входные данные.
Главное что для них есть место.
Всем известное место.
Повсеместно используемое место.
и если бы это место еще использовалось бы при инициализации любого экземпляра, то это было бы замечательно. Ну хотя бы с дефолтным нуллом.
Наподобие мэйн.
На крайняк всегда можно перекрыть метод new и добавить - изменить входные параметры...
Старый 10.06.2017, 10:09   #110  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
Повсеместно используемое место.
Это все равно, что AnyType - потому, что никто никогда не будет знать что туда положить чтобы код корректно работал либо придется приводить описание используемых параметров в документации к классу, только оно не будет проверяться компилятором и возникать в подсказках .

Почитайте про design by contract и вообще про принципы проектирования
Старый 10.06.2017, 13:20   #111  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от belugin Посмотреть сообщение
Это все равно, что AnyType
Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Можно считать, что это типизированная передача фиксированных параметров в контракте. Возможно, для некоторых классов избыточная. Но зато (если бы это было так) унифицированная для всех объектов системы! А это приводит в порядок мысли в голове разработчиков новой функциональности, и конкретным ожиданиям для существующей. И на 90%!!! исключает зоопарк в передаваемых структурах данных при инициализации.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован. Поэтому использование его в контракте не является правильным решением.
Проверка переданных данных лежит полюбому на создаваемом классе.
---------
Вы же не будете утверждать, что использование контракта избавляет от необходимости проверки входных данных?
За это сообщение автора поблагодарили: mazzy (2), ax_mct (5).
Старый 10.06.2017, 15:32   #112  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Почитайте про design by contract и вообще про принципы проектирования
Вот лучше бы те кто такое читают в Аксапту бы не лезли. Ей от этого дурно, а сейчас вообще подыхает

Всякие банды четырех решали конкретные проблемы, а не мифические. Я даже не знаю что хуже -индусские реализации плоской земли или когда при изготовлении табуретки используются все знания про многомерность Солнечной системы.

Те же эти атрибуты чтобы пометить классы при вызове извне - типичный пример overengineering.
Круто, красиво, талантливо. Но до тех пор пока это не упрощает решение уже существующих проблем - это ненужная хрень.

Я например не вижу как это что-то упрощает или экономит в контексте даже AX7. Не нужно загодя решать потенциальные проблемы. Это overengineering.
Старый 11.06.2017, 00:58   #113  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Brian decides a magic climbing fork is the best way to climb into the tower to retrieve the amulet and get home.
https://www.youtube.com/watch?v=44IgPvJJpa0
Старый 11.06.2017, 07:40   #114  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ta_and Посмотреть сообщение
Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован.
Так args содержит any type. И 90% классов (кстати интересно вообще всех классов или классов, которые вы добавляете/изменяете) принимают не запись вообще а запись какого-то определенного типа. И энам тоже не любой. И указывание не нужных параметров создает кашу в голове а не приводит мозги в порядок.

Цитата:
Поэтому использование его в контракте не является правильным решением.
Проверка переданных данных лежит полюбому на создаваемом классе.
---------
Вы же не будете утверждать, что использование контракта избавляет от необходимости проверки входных данных?
Почитайте про design by contact - это не то же самое что data contracts .

Да проверять нужно по-любому. По крайней мере пока нет зависимых типов. Но я бы сделал наоборот - не передавал бы везде запись и enum - нужны они там или не нужны а в menu item поздравлял бы указывать только те параметры которые принимает main: нужна запись - попросить запись причем нужного типа, нужен enum - попросить enum, нужно два - просить два.

Вы же сами не хотите any type - потому что нужна проверка при компиляции. Но почему-то хотите any record и anyenum.

Статическая проверка типов и их явное указание решает сразу несколько проблем - некоторые классы ошибок будут видны сразу в процессе редактирования (не надо тестировать силы понять что типы неправильные), избавляют от некоторого документирования - типы уже указаны к тому же в отличие от args параметры можно назвать - не parmString а taxcode.
За это сообщение автора поблагодарили: ta_and (3).
Старый 11.06.2017, 07:43   #115  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Вот лучше бы те кто такое читают в Аксапту бы не лезли. Ей от этого дурно, а сейчас вообще подыхает

Всякие банды четырех решали конкретные проблемы, а не мифические. Я даже не знаю что хуже -индусские реализации плоской земли или когда при изготовлении табуретки используются все знания про многомерность Солнечной системы.

.
Откуда вы решили что это из книжек по проектированию . Про overengineering там тоже есть.
Старый 11.06.2017, 19:18   #116  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Откуда вы решили что это из книжек по проектированию . Про overengineering там тоже есть.
Наши знания и компетентность - отдельно, Аксапта и уместность для нее паттернов - отдельно.

Мой пойнт в том что любые паттерны проектирования - overengineering. В том числе данный патентованный способ использования атрибутов. Оverengineering до тех пор пока не доказано и показано обратное. Как с той вилкой для подьема по стене.

Аксапта уже имела достаточно своих паттернов и сложившийся Best Practices, любое привнесение новых паттернов (на фоне наплевательства в системном коде на платформу как таковую), - кроме удорожания программирования ничего не с собой не несет.

Что эти аттрибуты, что идея с anytype - это чужеродные отягощающие систему элементы без какой-либо практической пользы.
За это сообщение автора поблагодарили: skuull (-1), fed (3).
Старый 11.06.2017, 23:08   #117  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от belugin Посмотреть сообщение
только те параметры которые принимает main
Эти слова да МС бы в уши... Но это другой уровень организации вызова объектов. Слишком кардинально нужно менять всю систему. Это уже не один параметр, это меняет не только один системный вызов обжекта, но требует изменения всей среды разработки и передачи событий между объектами... В общем, это на порядок более нереальная придумка, чем моя с аргс. )) Хотя, я полностью ЗА!
Старый 12.06.2017, 10:04   #118  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я бы переформулировал проблему, затронутую ax_mct следующим образом: Мы занимаемся автоматизацией бизнес процессов. Заметная часть участников этих самых бизнес процессов - люди весьма среднего образования и интеллекта. Поэтому все слишком сложно спроектированные бизнес-процессы, с течением времени либо упрощаются либо умирают.
Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована. Если бизнес-процесс описан правильно, то и код не будет выглядеть как набор примеров из Gang Of Four. Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.
Мы ведь в конце концов не биржевой скальпер пишем, не программу игры в Го и не предсказатель погоды. Если у вас разработка без десятка паттернов не получается, попробуйте с постановщиком поговорить.Скорее всего, он просто какой-то бред в спецификации написал, или вы просто половины требований не поняли...

Последний раз редактировалось fed; 12.06.2017 в 11:01.
За это сообщение автора поблагодарили: ax_mct (5), sukhanchik (5), Logger (3), kvan (3).
Старый 12.06.2017, 11:35   #119  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от fed Посмотреть сообщение
Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.
Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.
Старый 12.06.2017, 11:53   #120  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от EVGL Посмотреть сообщение
Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.
Гм. Про предварительный просмотр я помню конечно. Проблема в том, что вместо предварительного просмотра сделали монстра, который позволяет отвязать проводки от экономического смысла операции. Кроме того - они там почему-то решили оторвать разноску в ГК от разноски по модулю, ввести понятие исходного документа (который вообще-то не само экономическое событие, а просто некий полуслучайный носитель информации об экономическом событии) и тд и тп.
Собственно из за бредовости привязки экономического события к документу и случилось что "только 30% мест" были покрыты.
Кроме того - возможность посмотреть планируемые проводки до разноски - это такая удобная фича. Она полезна конечно, но вряд ли настолько полезна чтобы сломать механизм разноски и отвязать разноску в ГК от разноски по модулю...
В итоге - я бы сказал что 85% багов в финансовом модуле DAX2012 случались как раз из за того что этот монстр как-то не очень хорошо интегрировался с остальными местами системы...
Теги
sysextension framework, sysoperation framework, как правильно, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stephenmann: Technical History of Dynamics AX - From Axapta 3.0 to AX2012 Blog bot DAX Blogs 5 03.03.2017 10:22
dynamicsax-fico: Invoice search AX2012 vs. AX7 (Part 2) Blog bot DAX Blogs 0 01.04.2016 10:11
DAX2009 аналог friend классов. Как сделать? Raven Melancholic DAX: Программирование 9 07.11.2015 23:50
emeadaxsupport: Inventory closing differences between AX4.0 and AX2012 using weighted average costing method Blog bot DAX Blogs 0 27.12.2012 19:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:03.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.