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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.06.2008, 09:34   #21  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Простите, а чем это отличается функционально от выбора в какой-либо настройке некоего значения Enum'а
1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок

В принципе, еще куча мелких проблем. Для знакомства со всеми ними достаточно плотно поработать с модулем "Расчеты с персоналом", функционалом счетчиков, например. Дебажить... Да, только и остается, что дебажить - втрое больше времени занимает, но ничего другого нам не оставили.
Старый 04.06.2008, 10:16   #22  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от Yprit Посмотреть сообщение
1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок
В вопросе ключевым словом было "функционально" и по сути своей больше к консультанту относилось. Именно функционально в плане работы логики - фактически ничем не отличается. Про программиста в принципе изначально ясно было.

Про перекрестные спасибо - совсем про них забыл что-то я.

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

Последний раз редактировалось TasmanianDevil; 04.06.2008 в 10:28.
Старый 04.06.2008, 10:54   #23  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
N-угольные колеса вместо круглых ?
А потом при появлении нового варианта перетачивать на (N+1)-угольное, то бишь допрограммируя ?
Можно я повторюсь?
Цитата:
Сообщение от mazzy Посмотреть сообщение
Да, конечно, если программист захочет добавить функционал, то в первом случае он должен добавить всего лишь один метод, а во втором - расширить обертку. Но это только кажется. Поскольку в первом случае "настраивать" систему сможет только програмист. Поэтому в первом случае программист делает никому не нужную работу - вместо того, чтобы просто запрограммировать выбор в коде, он делает никому не нужный интерфейс, которым сможет воспользоваться только он сам (и то только в первое время - потом забудет как это работает и все равно полезет в код по новой).
__________________
полезное на axForum, github, vk, coub.
Старый 04.06.2008, 10:55   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
один из возможных путей построения всяких удобностей.
Удобностей для кого?
Можно привести примеры удобностей?
__________________
полезное на axForum, github, vk, coub.
Старый 04.06.2008, 11:40   #25  
axaLearner is offline
axaLearner
Участник
 
88 / 17 (1) ++
Регистрация: 24.06.2004
Адрес: God knows
Имхо, нормальная задача. Как пример, универсальный генератор отчетов. Создается word - шаблон с закладками. В настройках системы этот шаблон указан. И есть функциоанальность настройки этого отчета - открывается форма вроде SysQueryForm, где в гриде показаны все закладки нашего шаблона, пользователь может скомпоновать запрос (стандартное добавление источников данных в SysQueryForm) и каждой зайкладке поставить в соответствие поле либо display метод, что особенно критично если принять во внимание невозможность создания больших и вервистых запросов в связке DAX + MSSQL. Предположим этот отчет вызывается из карточки сотрудника; пользователь запускает отчет, который из отфильтрованного по текущему сотруднику Query, тянет поля и методы источников данных в отчет.
В принципе, программировать все равно надо, но для добавления нового отчета надо всего лишь добавить в параметрах системы ссылку на его шаблон и сделать кнопку на форме. Но согласитесь, очень удобно то что пользователь может сам добавлять новые закладки в шаблон и без участия программиста связывать их с источниками данных системы, вносить изменения.
PS. Мы такое реализовали на одном из проектов, как раз в модуле управления персоналом.
Старый 04.06.2008, 12:27   #26  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Ваше описание основано на одном предположении
Цитата:
Сообщение от axaLearner Посмотреть сообщение
пользователь может скомпоновать запрос
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода

Да, я знаю, что такие пользователи есть. Но их единицы. Мы рассказываем о такой возможности SysQueryForm всем пользователям. Но пользуются этой фичей единицы. И то только если консультант создаст запрос и сохранит его в списке используемых запросов.

Итак, повторюсь: вы делаете, делаете некую супер-фичу. Ваша супер-фича основывается на том, что пользователь будет формировать запрос.
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос?
__________________
полезное на axForum, github, vk, coub.
Старый 04.06.2008, 12:56   #27  
axaLearner is offline
axaLearner
Участник
 
88 / 17 (1) ++
Регистрация: 24.06.2004
Адрес: God knows
Цитата:
Сообщение от mazzy Посмотреть сообщение
Ваше описание основано на одном предположении...
Если вы склонны цепляться к словам, то я лишь уточню, что под пользователем системы я имелл ввиду человека, который будет настраивать этот отчет. Как правило у клиента есть человек, которой "на ты" с системой, будь то внутренний консультант или специалист поддержки, для которого задача модификации отчета сведется к минимальной настройке. Я лишь хотел показать ПРАКТИЧЕСКОЕ использование обозначеннного в названии данной ветки предмета и ни в коем случае не ввязываться в обсуждение "человеко\добавьте свое-ориентированных" подходов.
Старый 04.06.2008, 13:08   #28  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от axaLearner Посмотреть сообщение
Если вы склонны цепляться к словам
Я целпяюсь не к словам, а к смыслу.

Цитата:
Сообщение от axaLearner Посмотреть сообщение
то я лишь уточню, что под пользователем системы я имелл ввиду человека, который будет настраивать этот отчет.
Начинается... Пошли "уточнения" в ТЗ, которые полностью меняют смысл
Даже не спрашиваю, знает ли об этом "уточнении" заказчик...

Цитата:
Сообщение от axaLearner Посмотреть сообщение
Как правило у клиента есть человек, которой "на ты" с системой, будь то внутренний консультант или специалист поддержки, для которого задача модификации отчета сведется к минимальной настройке.
А можно я себя процитирую? Обратите внимание - никаких уточнений. Только цитата:
Цитата:
Сообщение от mazzy Посмотреть сообщение
Поэтому в первом случае программист делает никому не нужную работу - вместо того, чтобы просто запрограммировать выбор в коде, он делает никому не нужный интерфейс, которым сможет воспользоваться только он сам (и то только в первое время - потом забудет как это работает и все равно полезет в код по новой).
Цитата:
Сообщение от axaLearner Посмотреть сообщение
Я лишь хотел показать ПРАКТИЧЕСКОЕ использование обозначеннного в названии данной ветки предмета и ни в коем случае не ввязываться в обсуждение "человеко\добавьте свое-ориентированных" подходов.
Ок, ок. Цитирую вас: "ПРАКТИЧЕСКОЕ использование ... предмета ... пользователем ... которой "на ты" с системой."

Именно это я и называю - вместо того, чтобы решать задачи пользователя, решаются чисто програмистские задачи.
См. мой комментарий №4 здесь Значение display метода по его названию
__________________
полезное на axForum, github, vk, coub.
Старый 04.06.2008, 13:30   #29  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Ежели есть еще какие подводные камни - поведайте, буду весьма благодарен, особенно если на проекте в аттачменте приведете примеры таких проблем.
1. Название вариантов enum-а несет в себе гораздо больше смысловой нагрузки, чем Id класса. В сложных расчетах этот параметр передается через 10-к методов, а иногда и контейнеров, в результате определить, что послужило причиной создания данного объекта и почему он являеся инстансом данного класса невозможно или очень сложно.
2. Т.к. перекрестные порушены, совсем не весело вносить существенные изменения в такой механизм. Т.к. механизм искуственно усложнен + не работают проверки сигнатур, любые изменения могут привести к неожиданным эффектам.
3. Если писатель допустил ошибку, найти ее и исправить крайне тяжело.
4. Рушится сама прадигма ООП. Такие конструкции даже на функциональное программирование не тянут, это больше похоже на использование GOTO.
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Программисту - труднее(отсутствует в момент написания проверка на типы и количество аргументов и нет подсветки синтаксиса), консультанту же должно быть по барабану.
О чем и речь. Консультанту и пользователю от этого пользы никакой, разве что подтормаживает немного сильнее. Зато разработчику масса проблем. Спрашивается, для чего создаются такие "универсальные решения"?
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
В любом случае конечного вопроса не снимает - зачем сделана такая возможность ?
Для создания инструментов разработчика. К примеру, если хочется модифицировать или создать свой механизм экспорта/импорта данных, без подобных механизмов было бы очень сложно.
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Скорее всего поимел, ибо как правило, мысль о подобных "универсализмах" приходит после того как вдоволь "наелся" рутинным допрограммированием и просыпается разумная лень оптимизаторская, что не есть плохо, но вот хорошо ли это - зависит от реализации задуманного.
Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: Yprit (1), petr (1).
Старый 04.06.2008, 14:07   #30  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
2 Mazzy

Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

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

Какой по вашему вариант предпочтительнее?
Старый 04.06.2008, 14:54   #31  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от macklakov Посмотреть сообщение
Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.
Посидел, подумал, заодно по вопросам mazzy поприкидывал варианты серъезного прикладного применения - наверное все же приведенная цитата по идеологии ближе к истине. Удобности только для сервисных и девелоперских вещей получается.
В бизнес-логике, действительно, по-большому счету игра свеч вряд ли будет стоить при использовании Dict-семейства ...
__________________
Мы летаем, кружимся, нагоняем ужасы ...

Последний раз редактировалось TasmanianDevil; 04.06.2008 в 14:56.
За это сообщение автора поблагодарили: macklakov (1).
Старый 04.06.2008, 15:26   #32  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
2 Mazzy

Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

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

Какой по вашему вариант предпочтительнее?
Посидел, подумал, почитал ветку... В общем-то я тоже стронник Dict-классов ... был до прочтения ветки.
И вот призадумался - над Вашим вопросом, отнесенным правда не ко мне.
Вот что скажу. Возможно 2 варианта решения задачи:
Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия

Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта

Есть пример в системе - когда для каждой страны существует своя проверка корректности введенного банковского счета (Классы Bank_*). Есть енум (тип банк счета) и класс Bank, который, разруливает этот енум и создает наследника.

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

Последний раз редактировалось sukhanchik; 04.06.2008 в 15:29.
За это сообщение автора поблагодарили: mazzy (5).
Старый 04.06.2008, 16:10   #33  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия

Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта
Форматы не приниципиально разные, но их много и они постоянно добавляются. Практически каждый поставщик имеет свой, удобный ему формат. Если воспользоваться вариантом, где требуется программирование, то получим ситуацию, когда периодически будут приходить пользователи с просьбой "У нас появился новый поставщик, добавьте, пожалуйста, нам новый формат". Конечно при правильной структуре работы там не много и тестирование минимальное, но разве это правильно?
Получается, что при изменении значения параметра системы (новый поставщик) приходится менять ее структуру. По-моему неправильно "допиливать" систему при каждом появлении в ней новых данных.
За это сообщение автора поблагодарили: axaLearner (1).
Старый 04.06.2008, 16:40   #34  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Форматы не приниципиально разные, но их много и они постоянно добавляются. Практически каждый поставщик имеет свой, удобный ему формат.
...
Получается, что при изменении значения параметра системы (новый поставщик) приходится менять ее структуру. По-моему неправильно "допиливать" систему при каждом появлении в ней новых данных.
А я же не говорю про "допил". Есть разные варианты. У кого 5 поставщиков, у кого 25, а у кого они сотнями исчисляются
Я же сказал про конструктор (вариант 1). В этом случае - ничего "допиливать" не надо. Все делается настройками. Только конструктор главное правильно заложить. Причем - опять-таки - в зависимости от ситуации - конструктор может выродиться в группы определения.

Чем вариант с конструктором плох? Структура системы не меняется при изменения параметра системы.
Но при добавлении поставщика - ведь производятся какие-то действия? (банковский счет заводится, условия оплаты и прочая информация). Этот перечень расширяется на добавление группы определения (или ее аналога)

У Вас другое мнение?
__________________
Возможно сделать все. Вопрос времени
Старый 04.06.2008, 16:56   #35  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.
Можно я тоже встряну?

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

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

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

В принципе, есть еще вариант. Заставить поставщиков присылать файлы в определенном формате. Но тут вопрос в том, кто больше заинтересован в этой информации. Вы или поставщик.

Строго говоря, разговоры "вообще" обычно ничем хорошим не кончаются. Нужно знать конкретную ситуацию. Слишком много "но" и "если" влияющих на выбор того или иного способа решения.
За это сообщение автора поблагодарили: mazzy (5).
Старый 04.06.2008, 17:10   #36  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Чем вариант с конструктором плох? Структура системы не меняется при изменения параметра системы.
Но при добавлении поставщика - ведь производятся какие-то действия? (банковский счет заводится, условия оплаты и прочая информация). Этот перечень расширяется на добавление группы определения (или ее аналога)

У Вас другое мнение?
Я полностью за вариант конструктора. Меня заинтересовало вот что:

Цитата:
Сообщение от mazzy Посмотреть сообщение
Ваше описание основано на одном предположении

Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода

Да, я знаю, что такие пользователи есть. Но их единицы. Мы рассказываем о такой возможности SysQueryForm всем пользователям. Но пользуются этой фичей единицы. И то только если консультант создаст запрос и сохранит его в списке используемых запросов.

Итак, повторюсь: вы делаете, делаете некую супер-фичу. Ваша супер-фича основывается на том, что пользователь будет формировать запрос.
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос?
Конструктор будет сложной, понятной не каждому пользователю супер-фичей, не "человекоориентированный" подход, так сказать. Поэтому возник вопрос, как обойтись без этого в приведенной мною выше задаче?
Старый 04.06.2008, 17:25   #37  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Можно я тоже встряну?

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

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если пользователи достаточно продвинутые, то они смогут сам сконвертировать присланный текстовый файл под единый общий формат импорта. Не прибегая для этого ни к некоему механизму, ни к помощи программиста. В крайнем случае, просто вручную заведя нужную информацию.

А если все будет делать программист, то какая ему разница? Все-равно ему придется перестать программировать и заниматься только и исключительно постоянной подгонкой присылаемых файлов.
Это не рационально, да и вообще не реально. Настройки делаются один раз для одного поставщика, а конвертировать придется каждый файл. Тогда придется только и заниматься тем, что конвертировать файлы, независимо кто этим занимается.
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
В принципе, есть еще вариант. Заставить поставщиков присылать файлы в определенном формате. Но тут вопрос в том, кто больше заинтересован в этой информации. Вы или поставщик.

Строго говоря, разговоры "вообще" обычно ничем хорошим не кончаются. Нужно знать конкретную ситуацию. Слишком много "но" и "если" влияющих на выбор того или иного способа решения.
Дело не в конкретной задаче, она уже давно решена. Хочелось узнать какие есть еще варианты ее решения, кроме выше перечисленных, учитывая "человекоориентированный подход"
Старый 04.06.2008, 18:24   #38  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от macklakov Посмотреть сообщение
Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.
О! Полностью согласен.

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Уже ответили. Я согласен с уже высказавшимися ораторами.

Я только хотелось бы обратить ваше внимание, что требования: "импортировать в Axapta данные", "Унифицировать формат невозможно" взаимоисключающие.

Либо вы хоть как-то унифицируете (возможно не на 100%), либо каждый раз будете изобретать отдельный механизм. Первые шаги по унификации вы уже сделали, оговорившись, что формат являтся текстовым. Идите дальше. Определите обязательные поля (ИНН?, телефоны? адреса? наименование? артикул? артикул поставщика или ваш? Количество? Единицы измерения?)
Далее определите отношения 1:1, 1:N, N:N между полями.
Далее определите правила валидации. Правила, которые возвращают Истина, если данные валидны.

Видите, как много унифицировали?

Далее начинается положение полей в файле, в строке. Относительное и/или абсолютное. Скорее всего, под "унифицировать формат невозможно" вы имели в виду всего лишь то, что поля могут иметь разное положение. Но все равно вы ошибаетесь. Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли? Т.е. формат не может быть абсолютно произвольным? Все равно существуют какие-то инварианты (извините за использование термина).

Так вот. Первая задача выделить инварианты и дать возможность пользователям настраивать переменные параметры на том языке, на котором говорят пользователи. Но ни в коем случае не делать настройки на языке display-методов или callObject'ов и другой программисткой фигни.

Если же вы сознательно выбираете машиноориентированный подход, то не мучайтесь и юзайте штатный механизм импорта из текстовых файлов, как здесь уже посоветовали. http://axapta.mazzy.ru/lib/import/

Цитата:
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.
Есть еще варианты:
3. юзать импорт
4. переносить данные макросами http://axapta.mazzy.ru/lib/easyimport/
5. не импортировать, а заставить набивать в вашу систему ваших пользователей
6. не импортировать, а заставить набивать в вашу систему ваших поставщиков
7. не импортировать, а сделать сервис и опубликовать его, чтобы поставщики сами программировали общение с вашим сервисом
8. другие варианты

Главное - не зашоривать сознание

Цитата:
Минус первого варианта - каждый раз, при добавлении новых поставщиков (форматов файлов) придется программировать
Минус второго - пользователь (имеется в виду тот, кто занимается настройкой системы) должен иметь достаточную квалификацию, чтобы произвести настройку.

Какой по вашему вариант предпочтительнее?
Зависит от: если у вас нет пользователей с достаточной квалификаией, то просто каждый раз программируйте простое решение. Только перед программированием выделите инварианты и создайте нормальный, расширяемый базовый класс. Ни в коем случае не DictTable


Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия
Абсолютно согласен.
Причем настраивать все равно будет разработчик, поскольку для нормального импорта надо знать структуру базы

Цитата:
Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта
При правильном проектировании базового класса дело одного-двух дней.

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Форматы не приниципиально разные, но их много и они постоянно добавляются. Практически каждый поставщик имеет свой, удобный ему формат. Если воспользоваться вариантом, где требуется программирование, то получим ситуацию, когда периодически будут приходить пользователи с просьбой "У нас появился новый поставщик, добавьте, пожалуйста, нам новый формат".
Используя настройки типа "выбор dispaly-метода" или "настройка групп определения" вы не решите эту проблему. Все равно будут приходить к программисту и говорить - настрой пожалуйста

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Конечно при правильной структуре работы там не много и тестирование минимальное, но разве это правильно?
А почему нет, если другими решения все равно может настраивать только разработчик?

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Получается, что при изменении значения параметра системы (новый поставщик) приходится менять ее структуру. По-моему неправильно "допиливать" систему при каждом появлении в ней новых данных.
Неправильная логика.
Появляется не новый поставщик, а новый формат данных.
Нужен новый драйвер.

Тут самое главное - без фанатизма.

Человекоориентированный подход подразумевает, что программа ждет от него данных на понятном ему языке, что человек понимает что надо делать. Поэтому некоторые понятные человеку параметры вполне можно делать параметрами. Например, "начать импорт со строки с номером", "параметр начинается в колонке с номером". Но ни в коем случае нельзя давать человеку выбрать один из display-методов, ни в коем случае нельзя делать бесконечное число галочек и т.п.


Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Я же сказал про конструктор (вариант 1). В этом случае - ничего "допиливать" не надо. Все делается настройками.
ВСЕ - нехорошее слово.
Как только появляется слово ВСЕ - жди логической ошибки.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Для начала следует определится, являются ли Ваши пользователи достаточно продвинутыми, чтобы подстроится под нужный формат или процесс подстройки все-равно будет делать программист.
Абсолютно согласен.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если пользователи достаточно продвинутые, то они смогут сам сконвертировать присланный текстовый файл под единый общий формат импорта. Не прибегая для этого ни к некоему механизму, ни к помощи программиста. В крайнем случае, просто вручную заведя нужную информацию.
Абсолютно согласен.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
А если все будет делать программист, то какая ему разница? Все-равно ему придется перестать программировать и заниматься только и исключительно постоянной подгонкой присылаемых файлов.
Золотые слова!

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Конструктор будет сложной, понятной не каждому пользователю супер-фичей, не "человекоориентированный" подход, так сказать. Поэтому возник вопрос, как обойтись без этого в приведенной мною выше задаче?
А зачем обходится?
Вопрос так, не стоит по-моему.

Вопрос стоит так: если вы сознательно выбрали машиноориентированный подход, то не надо рассчитывать, что настравать будут пользователи. Будете сами настраивать. Если же вы делаете инструмент для пользователей, то не надо выдумывать программистские задачи. Надо решать проблемы пользователей.

Как сказал macklakov: "Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике."

Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Дело не в конкретной задаче, она уже давно решена. Хочелось узнать какие есть еще варианты ее решения, кроме выше перечисленных, учитывая "человекоориентированный подход"
Прежде всего надо разобраться с форматом файлов.
Ошибка проектирования находится в предположении, что форматы уникальны и их нельзя унифицировать. Такого не бывает. Ведь пользователи их как-то читают
__________________
полезное на axForum, github, vk, coub.
Старый 05.06.2008, 10:09   #39  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от mazzy Посмотреть сообщение
Axapta данные", "Унифицировать формат невозможно" взаимоисключающие.
Я имел в виду что невозможно сделать так, чтобы форматы были на 100% одинаковыми. Во всем остальном согласен.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Далее начинается положение полей в файле, в строке. Относительное и/или абсолютное. Скорее всего, под "унифицировать формат невозможно" вы имели в виду всего лишь то, что поля могут иметь разное положение. Но все равно вы ошибаетесь. Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли? Т.е. формат не может быть абсолютно произвольным? Все равно существуют какие-то инварианты (извините за использование термина).
Не только положение. Инициализация поля определенным значением, при определенных условиях. Например, дата поставки равна текущей дате, если такого поля в файле нет (условия и значения определяются спецификой предметной области и наперед известны), удаление определенных символов из определенных полей, добавление суффиксов и префиксов. Согласен, это и есть унификация пусть не на 100%.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли?
Именно эти файлы НЕ читают. Это файлы только для электронного обмена данными между системами. Они читают соответствующие бумажные документы, а они не похожи на файлы. То что удобно читать пользователю далеко не всегда удобно читать программно.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Так вот. Первая задача выделить инварианты и дать возможность пользователям настраивать переменные параметры на том языке, на котором говорят пользователи. Но ни в коем случае не делать настройки на языке display-методов или callObject'ов и другой программисткой фигни.
Так и сделано. Пользователь не выбирает таблицы и поля по их названию в АОТ, но он выбирает по их label в какое поле загружать те или иные данные. Пользователю это не заметно, но в коде используются классы DictTable/DictField. Это я вот к чему:
Цитата:
Сообщение от mazzy;
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода
В общем мнение понял, спасибо, но не со всем согласен. Действительно не каждый пользователь может разобраться как настраивать импорт, но ведь задачу программист не сам придумывает. Какая постановка задачи, таково должно быть и решение. Если задача ставится так: хочу чтобы данные от поставщиков появились в Аксапте. То наверное и не стоит делать сложных универсальных механизмов, с кучей галочек и т.п. - все равно никто не будет настраивать. А если задача ставится так: Хочу механизм, который бы позволил импортировать данные, подстраиваться под формат поставщика, чтобы я мог сам все настроить, форматы бывают такие, такие и еще вот такие. Вот тогда есть смысл унифицировать форматы (насколько это возможно) и делать конструктор. Раз человек смог поставить такую задачу, значит он понимает о чем говорит и значит сможет настроить. Как замечено выше - пользователь должен работать с интерфейсом на понятном ему языке, но пользователи-то бывают разные. Конечно постановок задач по первому типу во много раз больше, чем по второму, но и такое тоже может быть. Не стоит говорить, что все пользователи не поймут, не разберутся. Как там говорится про слово ВСЕ

Последний раз редактировалось Lucky13; 05.06.2008 в 10:12.
Старый 05.06.2008, 10:13   #40  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
В общем мнение понял, спасибо, но не со всем согласен.
И это классно!
__________________
полезное на axForum, github, vk, coub.
Теги
display метод

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Вызов display метода Ashir DAX: Программирование 4 08.12.2005 16:32
Не копирует из display-метода в буфер обмена akvi DAX: Программирование 6 08.12.2005 13:14
кэширование display метода macklakov DAX: Программирование 6 03.12.2005 14:58
Можно ли задать Caption для display-метода? Andronov DAX: Программирование 6 29.05.2003 14:18
edit и display методы Maxim Gorbunov DAX: База знаний и проекты 4 15.01.2002 12:58
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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