Обучение на Microsoft Certified IT Professional – Developer for Microsoft Dynamics NAV

[Alterant]

Начнем с того, что программистов на с гораздо больше, чем на NAVе. Поэтому и книжек и тех, кто занимается методологией гораздо больше. Это нужно принять как данность.
Также хочу заметить, что красивое, элегентное, удобное не всегда - хорошо. Точнее не всегда хорошо, применительно к какой-то конкретной задаче. А будет ли код красиво написанный в соответсвии с тем или иным подходом оптимально работать с памятью? Работать быстро. Как пример могу привести программу Evernote. Прошлую версию разработчики написали на красивом и модном WPF. По получили огромное количество проблем - проблемы с отображением шрифтов, медленную работу, огромное использование памяти и, как следствие, недовольство пользователей. Текущую версию они переписали на плюсах. Но, разумеется, я не утверждаю, что так всегда. Бывает, что новые подходы улучшают какие-то аспекты без ущерба для других.

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

[Predatore]

Цитата:

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

Начнем с того, что программистов на с гораздо больше, чем на NAVе. Поэтому и книжек и тех, кто занимается методологией гораздо больше. Это нужно принять как данность.
Также хочу заметить, что красивое, элегентное, удобное не всегда - хорошо. Точнее не всегда хорошо, применительно к какой-то конкретной задаче. А будет ли код красиво написанный в соответсвии с тем или иным подходом оптимально работать с памятью? Работать быстро. Как пример могу привести программу Evernote. Прошлую версию разработчики написали на красивом и модном WPF. По получили огромное количество проблем - проблемы с отображением шрифтов, медленную работу, огромное использование памяти и, как следствие, недовольство пользователей. Текущую версию они переписали на плюсах. Но, разумеется, я не утверждаю, что так всегда. Бывает, что новые подходы улучшают какие-то аспекты без ущерба для других.

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

Ну это понятно, что сишников гораздо больше и это объясняет, почему книг больше, но не объясняет, почему по NAV книг почти нет вообще. Ну нет и нет, я спрашивал про книги и получил ответ.
Перечисляя удобный, логичный, красивый и т.д. код, я забыл наверное упомянуть и слово оптимальный. Оптимальность конечно же тоже входит в понятие правильного кода.
А насчёт WPF и не только, мой любимый и очень хороший преподаватель по информатике Валерий Абрамович Оргун, говорил так: "Язык - это инструмент и под каждую задачу нужно выбирать тот инструмент, который для неё более подходит."
По примеру, я тестировал на NAV 5.0, может я что-то не так понял, но я создал массив типа Record, скажем с именем temp и дальше проделал следующее:
temp[1].text := 'какой-то текст';
temp[2].text := 'другой текст';
MESSAGE (temp[1].text);
Если бы temp[1] и temp[2] ссылались бы на одну таблицу, то сообщение было бы 'другой текст', но у меня высветилось сообщение 'какой-то текст'. Из чего я и сделал вывод, что это всё-таки разные таблицы.

[Alterant]

Цитата:

По примеру, я тестировал на NAV 5.0, может я что-то не так понял, но я создал массив типа Record, скажем с именем temp и дальше проделал следующее:
temp[1].text := 'какой-то текст';
temp[2].text := 'другой текст';
MESSAGE (temp[1].text);
Если бы temp[1] и temp[2] ссылались бы на одну таблицу, то сообщение было бы 'другой текст', но у меня высветилось сообщение 'какой-то текст'. Из чего я и сделал вывод, что это всё-таки разные таблицы.

Я говорил про работу с таблицей. Ясно, что каждый элемент массива - это отдельный объект, и при присвоении каждый будет хранить свое значение. Я не зря говорил именно про таблицу, т.к. работать они будут с одной и той же таблицей:
temp[1].PK := 1;
temp[1].Text := 'Текст';
temp[1].Insert;
temp[2].get(1); <- тут не будет ошибки, т.к. и temp[1] и temp[2], хоть и разные экземпляры, но манипулирут одной и той же таблицей.
MESSAGE(temp[2].Text); <- выдаст "Текст"