добрый день! Подскажите, пожалуйста, где лучше писать код? в модуле формы или в модуле объекта? и почему?

А какое мыло лучше использовать: туалетное или хозяйственное?

(1) Жидкое )

(1) в плане быстродействия разницы нет?

в модуле менеджера

С таким подходом лучше не писать совсем

(3) От мыла к мылу быстродействие различается. Категория вот прям ни о чём не говорит.

На самом деле лучше всего писать код на бумажке. Это стимулирует тщательнее обдумывать каждую строчку )

(0) В модуле общем.

Чо привязываться к объекту, буквы-то одинаковые - пусть все используют!

(8)Глобальном. Единственном. Чтоб не запутаться.

Если для вас быстродействие - единственный критерий, пишите на асме, че уж там.

(0) а что за код пишем? создаем программно реквизиты? или документ проводим?

(0) Код лучше всего писать там, где он будет использоваться максимально эффективно.

(13) На клавиатуре банкомата.

Лучше писать на Мисте. Здесь все само исправиться...

+(14) набрал 4 знака - получил деньги. Максимальная эффективность.

(0)
а) зависит от субъекта работы кода (элементы\реквизиты формы, реквизиты объекта, другие данные в бд)
б) зависит от контекста работы кода (происходит работа только с элементами\реквизитами формы\объекта ИЛИ используются данные бд)
в) зависит от размещения кода - только на клиенте или на сервере тоже.

Если надо изменить именно этот объект - модуль объекта.
Если оперируешь только ссылками - модуль менеджера.
На форме только работа с формой.

Для проверки, все ли сделано как надо - надо смотреть, достаточно ли методов в модуле объекта и в модуле менеджера для того, чтобы создать объект программно.

(0) На заборе: "Здесь был Вася."

(16) На кассе в столовой ещё эффективнее - набрал 4 цифры, получил тарелку супа минуя наличные деньги

(19) А мат между словами - кодом: FFA0EA... чтоб никто не догадался

(20) Это не наш метод! За тарелку-то супа...

(21) Можно и в подписи :)

(23) Только если в квалифицированной цифровой. На весь забор, чтоб

На самом деле, в компании 1С тоже ни как не могут определиьтся воти пишут там и там, а некоторые еще не могут определиться нужен им клиентский модуль или серверный и указывают сразу и на клиенте и на сервере

(25) сразу и на клиенте и на сервере - означает что код должен одинаково работать как на клиенте, так и на сервере.

(0) Смотря кто пишет, программист или старший программист...

В голове

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

Разрабатывая программу на Visual Basic, который тогда находился на раннем этапе развития, я с огорчением обнаружил, что язык не поддерживает встроенных способов разделения бизнес-логики, кода GUI и кода работы с БД. Я знал, что, если буду невнимателен, со временем некоторые из моих «форм» Visual Basic включат в себя код бизнес-логики, другие — код доступа к БД, а остальные не будут содер# жать ни того, ни другого — в итоге я не смогу вспомнить, какая форма за что отвечает. Я только что завершил работу над проектом C++, в котором разделение кода было выполнено плохо, и не хотел еще раз наступать на те же грабли. Поэтому я принял конвенцию, в соответствии с которой файлам .frm (файлам формы) дозволялось только извлекать данные из БД и сохранять их обратно, но не передавать эти данные другим частям программы.
…
Принятая мной конвенция была очень проста, но по мере развития проекта я обнаружил, что она помогла мне избежать многих случаев, в которых мне пришлось бы писать неестественный код. Так, мне пришлось бы загружать формы, но держать их скрытыми, чтобы можно было вызвать реализованные в них методы проверки корректности данных, или мне пришлось бы копировать код форм в другие места программы и сопровождать этот параллельный код.

(c) С.Макконел, "Совершенный код"

(28) В голове код писать нельзя. Там места мало.

в УФ

1. модуль объекта не доступен из клиентских вызовов формы
2. для вызова кода из модуля объекта надо сначала сериализовать реквизит формы в объект, при чем при каждом серверном вызове....

самое лучшее код для формы писать
форма+общий модуль

(32) "для вызова кода из модуля объекта надо сначала сериализовать реквизит формы в объект, при чем при каждом серверном вызове...."

Разве в этом есть какие-то сложности или трудности?

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

(34) > и так существует на сервере на момент вызова.

нет

(4) +1 в большинстве случаев. Так как при этом подходе для вызова алгоритма не потребуется дополнительных строк кода для получения объекта или формы. Вот в форме код который вызывается извне пишут только мудаки - ненавижу такой стиль.

(33) если объект маленький - не сложно, если в нем 5 ТЧ по 1000 строк (например такие документы в ЗУП очень часто встречаются) - то уже будет совершенная лишняя нагрузка

(34) это не так, полноценный объект существует только внутри НЕКОТОРЫХ предопределенных событий (например "ПриЗаписиНаСервере")


кроме того УФ в прицепе не позволяет сохранять на сервере любые переменные и объекты... Что-бы сохранить любой Объект между двумя клиентскими вызовами нужно весьма и весьма извратится

(35) да, действительно, проверил. Объект существует при считывании из ИБ, записи в ИБ, и при вызове.

(37) в том же ЗУПе все бизнес-методы расположены в модуле объекта/менеджера. Т.е. можно сделать примерно так:

ДокументНачисления = Документы.НачислениеЗарплаты.СоздатьДокумент();
ДокументНачисления.ЗаполнитьСотрудниками();
ДокументНачисления.РассчитатьНачисления();
ДокументНачисления.Записать();

а в модуле формы лишь интерфейсная логика, и это правильно.

(39) ппц.... слов нет...

мы говорим об форме документа, а не обработке...

(40) разработчики типовых стараются придерживаться принципа, описанного в (30)
и совершенно не важно, форма документа, справочника или обработки. Я бы даже сказал, для документа это ещё более актуально, чем для обработки. Обработку не так часто приходится выполнять программно. А вот программно заполнять/корректировать документы приходится довольно часто.
Но и с обработкой не всё просто. Когда уровень автоматизации на предприятии возрастает, появляется желание запускать ту или иную обработку через регламентное задание. Если основная логика обработки будет расположена в форме обработки, то будет упс. Придётся этот код вытаскивать в форму объекта/менеджера, либо куда-нибудь копировать, что ещё хуже. И хорошо если код легко перетащить из формы в модуль объекта. Может получиться так, что код тесно завязан на реквизиты формы. Тогда придётся дополнительно покувыркаться, чтобы заставить всё это работать.
Лично я придерживаюсь принципа, что у любого объекта должен быть программный интерфейс, позволяющий выполнить основную его логику из кода. Ни разу не сталкивался, чтобы такой подход чем-то был неудобен. И наоборот, бизнес-логика, огульно засунутая в форму объекта, периодически вставляет палки в колёса и создаёт лишнюю работу.

"Вкалывают роботы, а не человек" (с)

Мы все занимаемся автоматизацией. Рано или поздно автоматизация доходит до такого уровня, когда операции перестают требовать пользовательского вмешательства, и начинают выполняться полностью автоматически. В рамках 1С функцию робота могут выполнять регламентные задания. Так вот, роботу требуется программный интерфейс, через который он будет выполнять те или иные действия. Если весь код расположен в форме, то подразумевается обязательное вмешательство пользователя. Форма должна быть открыта, и только после этого всё остальное. Это низкий уровень автоматизации. При высоком уровне автоматизации должна быть возможность выполнить некие действия исключительно программно. Форма в этом случае выпадает, как слабое звено. Поэтому стоит задуматься о размещении кода в модуле формы.

(43) >>>Форма должна быть открыта, и только после этого всё остальное

я Вас огорчу...

вполне рабочий код:

мФорма = ПолучитьФорму()
мФорма.МояОписанаяКакЭкспортнаяПроцедура()

(44) что так можно я знаю, но такой подход ну совсем не по фэншую. К тому же ПолучитьФорму() доступно только на клиенте. Как-минимум придётся дополнительно городить, чтобы форма с клиента приехала на сервер. Ведь основная бизнес-логика всегда выполняется на сервере.

Модно и молодежно писать код сюда:
http://catalog.mista.ru/public/707283/

(0) лучше начинать переставать писать код для неуправляемого режима. Превратишься в клюшкодава со временем, а вместо пальцев будут писюны

(44) за такой код скоро будут заплёвывать, как за клюшки

(47) не только за клюшки, но и за "обычные" формы..