Показать сообщение отдельно
Старый 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.