Вход | Регистрация
    1  2   

Зачем вообще нужна точка при обращении к реквизитам?

Зачем вообще нужна точка при обращении к реквизитам?
Я
   Mrbr
 
18.06.20 - 10:12
Все мы знаем, что обращение через точку эту моветон, лишняя нагрузка итд, что все нужные данные надо доставать запросом либо, например, БСПшным ОбщегоНазначение.ЗначениеРеквизитаОбъекта(). А нахрена тогда вообще точка и в каких случаях ей пользоваться? Если конфа точно не будет под нагрузкой? Если лень писать запрос?
И самое главное, почему 1С не поменяет механизм работы точки?
   LoneWanderer
 
1 - 18.06.20 - 10:17
>Если конфа точно не будет под нагрузкой? Если лень писать запрос?
Наверное, примерно так.

>И самое главное, почему 1С не поменяет механизм работы точки?
А есть идеи на что его менять? (кроме как сделать как в тонком клиенте - т.е. просто выкинуть)
   ДенисЧ
 
2 - 18.06.20 - 10:17
Твои предложения?
   dmpl
 
3 - 18.06.20 - 10:17
(0) Выборка данных запросом через прокладку очень быстро становится медленнее, если нужно значительное количество данных объекта. При чтении через точку при первом обращении объект читается, а затем он некоторое время кеширован, и последующие обращения через точку быстрее любых прокладок.
   Mrbr
 
4 - 18.06.20 - 10:22
(1) (2) Ну очевидно, что чаще нужно меньше половины реквизитов, а еще чаще 1-2. Поэтому через точку делать запрос на 1 указанный реквизит. Если нужно много реквизитов, то пишешь запрос.
   Волшебник
 
Модератор
5 - 18.06.20 - 10:23
Во-первых, это красиво...
   Mrbr
 
6 - 18.06.20 - 10:25
Интересно как работает точка в других ЯП с MVC моделью.
   dmpl
 
7 - 18.06.20 - 10:25
(4) И что что чаще? Вот как будет "всегда" - так можно и от точки отказываться.
   dmpl
 
8 - 18.06.20 - 10:28
(5) Во-вторых, это повышает скорость разработки и снижает затраты на сопровождение кода.

А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.
   mistеr
 
9 - 18.06.20 - 10:35
(0) Ошибка проектирования. Не заложили достаточно гибкости. Если хотя бы ТЧ и ЧЗ всякие не тянулись бы безусловно, уже было бы терпимо.

>почему 1С не поменяет механизм работы точки?

Поздно уже. Груз легаси кода неподъёмен.

(6) В других давно пришли к парадигме CQRS.
   mistеr
 
10 - 18.06.20 - 10:36
(9) "ЧЗ" --> "ХЗ"
   Fish
 
11 - 18.06.20 - 10:39
(0) "все нужные данные надо доставать запросом" - О ужас! В запросе тоже можно через точку доставать.
   Ненавижу 1С
 
12 - 18.06.20 - 10:40
На самом деле разработчики платформы достаточно ленивы
запросто можно было это представлять синтаксическим сахаром вызова запроса
   Волшебник
 
Модератор
13 - 18.06.20 - 10:46
(9) 1С очень легко отбрасывает легаси-код. Вспомните как сильно отличаются редакции типовых конфигураций. Один переход на УФ чего стоит
   Mrbr
 
14 - 18.06.20 - 10:48
(5) Запрос или ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Номенклатура, "Наименование") - красивее, чем Номенклатура.Наименование ???
(8) Аналогично и про скорость разработки.
   LoneWanderer
 
15 - 18.06.20 - 10:49
(12) Если получать реквизиты "поштучно" - это во многих случаях будет ещё хуже, чем получать объект целиком (накладные расходы на исполнение запроса съедят кучу времени).
   Волшебник
 
Модератор
16 - 18.06.20 - 10:49
(14) Нет
   RomanYS
 
17 - 18.06.20 - 10:58
(4) >> Если нужно много реквизитов, то пишешь запрос.
Как раз, если нужен одиночный объект почти полностью, то запрос писать не надо. Через точку самое то: накладные расходы на запрос будут сравнимы с чтением объекта в кэш.
   mistеr
 
18 - 18.06.20 - 11:18
(17) Если нет ТЧ.
   fisher
 
19 - 18.06.20 - 11:26
Тоже не понимаю, почему 1С не поменяет алгоритм работы точки. Вернее, вижу только одну причину - низкий приоритет этой задачи.
   fisher
 
20 - 18.06.20 - 11:31
Я точку иногда использую для упрощения кода, когда уверен что узким местом это не станет никогда и на увеличение общей средней нагрузки это тоже не повлияет. Т.е. не в цикле, на нетяжелых объектах и в нечасто запускаемых штуках. Оно как-то и нечасто приходится выбирать через точку или нет. Потому что обычно данные уже каким-то образом пакетно достаешь. А так, чтобы вот единичное обращение нужно было и приходилось решать через точку или нет - очень редко такое.
   DTX 4th
 
21 - 18.06.20 - 11:33
Первое правило оптимизации - не оптимизируй
   Serg_1960
 
22 - 18.06.20 - 11:34
"Все мы знаем, что обращение через точку эту моветон" - я бы не был столь безапелляционным. К реквизитам представления объекта - можно обращаться.Не моветон? К реквизитам объекта, ранее уже прочитанного в кэш - не моветон? И куда деть обратную совместимость, которую хочешь не хочешь, а тащить приходится. Вырастили хвост собаке -теперь уже не отрубишь.  А насчет запросов ради получения значений... запросы в цикле - тоже моветон :)
   Конструктор1С
 
23 - 18.06.20 - 11:39
Само по себе "через точку" допустимо и иногда оправдано. Недопустимы только особо рукожопые варианты. Например, когда в цикле перебираются много документов с кучей реквизитов и толстыми ТЧ, и при этом разработчик херачит данные через точку. У получения данных "через точку" есть один существенный плюс - уменьшается объём кода и повышается его читабельность
   trdm
 
24 - 18.06.20 - 11:46
(0) > И самое главное, почему 1С не поменяет механизм работы точки?

потому что всякие нубы не обладают пониманием того что точка это мета-конструкция которая позволяет писать коротко.

вОбъект2 = вОбъект1.Реквизит;
где:
.Реквизит - это инкапсуляция либо внутреннего запроса, либо получения данных из кеша значений.
внутренниый запрос обрабатывается уже скомпилированным кодом, которы быстрее кода на языке 1С.
   trdm
 
25 - 18.06.20 - 11:48
+(24) тем самым мы имеем:
1. скорость работы
2. укороченную запись.
эти 2 вещи - бесценны для разработки.
   fisher
 
26 - 18.06.20 - 11:49
(24) Да пусть "внутренний запрос" хоть четырежды скомпилирован. Если при этом тянется целиком объект - это нифига не очевидно и ни разу не оптимально в куче случаев. Причина у такой реализации была только одна - это было проще реализовать.
   Serg_1960
 
27 - 18.06.20 - 11:51
Хмм... имхо, есть ещё одна причина, когда считаю возможным отступление от канона и обращением к реквизитам "через точку": в угоду внесения минимально допустимых изменений в типовую версию.
   H A D G E H O G s
 
28 - 18.06.20 - 11:52
Если бы не точка - 1с8 не взлетела бы, когда толпы семерошников пришли в нее.
   fisher
 
29 - 18.06.20 - 11:54
Речь не про "точку", а про то как она реализована.
   Волшебник
 
Модератор
30 - 18.06.20 - 11:57
Точка — это символ ООП.
 
 Рекламное место пустует
   ДенисЧ
 
31 - 18.06.20 - 11:57
(26) Предлагаешь не кешировать объект, а каждый раз в базу лазять?
Что тянут всё сразу - да, как-то не очень, хз и тч можно бы и не брать...
   ДенисЧ
 
32 - 18.06.20 - 11:59
(30) В smalltalk, как образце ООП, точек практически нет
   fisher
 
33 - 18.06.20 - 12:00
(31) Конечно. Сейчас так и делают, только через БСП. Точку и предполагается при единичных обращениях использовать. Если хочешь закэшировать объект в "старом стиле" - это очень легко делается явно. И при этом все наглядно и понятно.
   Волшебник
 
Модератор
34 - 18.06.20 - 12:01
(32) smalltalk сыроват ещё
   ДенисЧ
 
35 - 18.06.20 - 12:05
(34) Сыровата 8ка. А смалталк - давно уже отработан...
   trdm
 
36 - 18.06.20 - 12:05
(26) > Да пусть "внутренний запрос" хоть четырежды скомпилирован.

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

не скрою, тоже думал об этом, что иногда получаем избыточный набор реквизитов объекта. И как бы я программировал "экономичные выборки". Типа:
вОбъект2 = вОбъект1.Реквизит("Код,наименование,промокод"); 

и мы влипаем в след. колизию: для "усеченного" объекта пришлось бы хранить в памяти словари усечения, т.е набор обрабатываемых реквизитов, тогда как для "неусеченного" объекта можно тупо использовать сингелтонные словари из метаданных. Это увеличит расход памяти на внутренний объект переменной, а их зачастую десятки тысяч.
Тут разрабам нужно выбирать тщательно.
   trdm
 
37 - 18.06.20 - 12:06
я говорил о разных разрабах, о тех кто пилит код самой платформы и о тех, кто скрриптует на 1С.
   Волшебник
 
Модератор
38 - 18.06.20 - 12:08
(35) Smalltalk уже давно на свалке истории
   fisher
 
39 - 18.06.20 - 12:09
(36) Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы. Вычитывание "мегатонного" объекта при попытке получения реквизита - это нефига не предсказуемое поведение. Чем больше неочевидной магии в системе - тем хуже "решает" средний разраб.
   ДенисЧ
 
40 - 18.06.20 - 12:13
(39) Если мы точно знаем, что при точке объект целиком читается в память всегда - это очень даже предсказуемо.
   RomanYS
 
41 - 18.06.20 - 12:13
(39) >> это нефига не предсказуемое поведение
Почему? Всё задокументировано. Новичок на эти грабли практически гарантировано наступает, способный хоть капельку думать осознает и запомнит.
   trdm
 
42 - 18.06.20 - 12:16
(39) Я бы не парился насчет "среднего разраба". Как выучится, такой и продукт будет. Это не проблема фирмы 1С.
   fisher
 
43 - 18.06.20 - 12:19
Дооооо. Конеееечно. Железный аргумент. Чтобы все было предсказуемо, нужно сначала выучить всю доку назубок. Так можно оправдать любую ересь. Главное, чтобы была задокументирована.
Только при наличии выбора любой вменяемый человек выберет из двух систем более предсказуемую. И в среднем на более предсказуемой системе будет совершаться меньше ошибок.
   Simod
 
44 - 18.06.20 - 12:19
Для тех, кому "мало" ЗначениеРеквизитаОбъекта() есть еще:
 - ЗначенияРеквизитовОбъекта()
 - ЗначенияРеквизитовОбъектов()
 - ЗначениеРеквизитаОбъектов()
   fisher
 
45 - 18.06.20 - 12:23
(41) "Новичок на эти грабли практически гарантировано наступает" - т.е. ты считаешь, что это норм? Вместо того, чтобы убрать грабли?
   ДенисЧ
 
46 - 18.06.20 - 12:23
(43) Переходи на жаваскрипт. Там документацию вообще читать не надо...
   trdm
 
47 - 18.06.20 - 12:26
(39) > Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы.

т.е. документацию изучить.
   Aleksey
 
48 - 18.06.20 - 12:26
В рекомендациях от 1С сказано что обращение через точку "позволяет создавать компактные запросы". И там не сказано что это моветон
   Aleksey
 
49 - 18.06.20 - 12:28
(36) ты придумал код из БСП. Так получаеются реквизиты контрагентов, организаций для печатных форм
   polosov
 
50 - 18.06.20 - 12:29
(39) Оба два решения не очень, поэтому 1С оставила делать выбор разработчику.
Если отдавать через точку, только нужный реквизит, то это повысит читаемость кода, но может привести к тому, что разрабы вообще не будут способны понимать, что если обрабатываешь большой или потенциально большой набор объектов, то нужные данные лучше сразу выбрать запросом. Вместо этого возможно долбежка СУБД мелкими запросами в циклах, для получения одного реквизита объекта.
   Aleksey
 
51 - 18.06.20 - 12:30
(60) особенно актуально когда тип - любая ссылка. Например поле регистратор. В обычном запросе можно ограничить выборку через выразить
   polosov
 
52 - 18.06.20 - 12:31
+(50) Ну и не так уж трудно запомнить, что при получении реквизита ссылки через точку будет получен весь объект.
   ДенисЧ
 
53 - 18.06.20 - 12:32
(48) Речь не о запросах
   fisher
 
54 - 18.06.20 - 12:41
(50) О да. Лучше подождать, пока разраб в своей практике не споткнется о внезапное кэширование больших объектов. Очень педагогично.
У разраба с минимальным бэкграундом в чем-то еще кроме 1С обязательно возникнет в голове вопрос - что происходит при обращении через точку. И интуитивно предполагаешь как раз точечное обращение к БД вместо ковровых бомбардировок.
(52) Это запомнить несложно. Но запомнишь ты это только после того как споткнешься или вычитаешь в доке. Будь иначе - этого бы запоминать не пришлось вовсе. И не пришлось бы пользоваться костылями из БСП.
Не вижу больше смысла спорить об очевидных вещах.
   polosov
 
55 - 18.06.20 - 12:45
(54) Тоже не вижу смысла спорить. Я просто не понимаю, почему нельзя запомнить простое правило и делать выбор в зависимости от ситуации.
   fisher
 
56 - 18.06.20 - 12:54
(55) Какое еще "можно", когда "нужно"? Речь о том, что можно было лучше. Но "стокгольмский синдром", вероятно, мешает это осознать.
   RomanYS
 
57 - 18.06.20 - 13:06
(45) Что ты считаешь граблями - кэширование? Или предлагается кэшировать объект частями?
Возможность прочитать объект в кэш и тысячу раз обратиться к его реквизитам без обращения к базе - реальная возможость, а не случайный баг.
   RomanYS
 
58 - 18.06.20 - 13:07
(56) Как было бы лучше?
   mistеr
 
59 - 18.06.20 - 13:15
(57) Возможное улучшение действительно может заключаться в разрешении частичного кэширования. И возможности указать (как в БСП), какие реквизиты потребуются в дальнейшем.

Но это сильно усложнит реализацию, особенно в части инвалидации кэша. Не факт, что оно того стоит.
   Волшебник
 
Модератор
60 - 18.06.20 - 13:43
(58) Можно было просто использовать Smalltalk, там нет точек при обращении к методам объектов. Тупо через пробел
 
 Рекламное место пустует
   dmpl
 
61 - 18.06.20 - 13:51
(43) А теперь сравни количество 1Сников и количество остальных программистов для бизнес-приложений ;)

(45) Т.е. ты предлагаешь не читать объект? Тогда как будет обеспечиваться синхронность данных, полученных в разные моменты времени? Блокировкой с уровнем изоляции REPEATABLE READ? Вы реально считаете, что это ускорит работу нагруженной системы?
   Ненавижу 1С
 
62 - 18.06.20 - 14:01
без точек:

context->push_back(make_shared<LocalVariableObject>(p->Name,p->Type,locVarVolume));
   RomanYS
 
63 - 18.06.20 - 14:34
(59) Думаю, оно того НЕ стоит
(60) Речь же не про синтаксис, а про поведение платформы при обращении через точку(или даже через Объект["ИмяРеквизита"]) Я не вижу альтернативного и при этом лучшего в 100% случаев поведения чем есть сейчас.
   mistеr
 
64 - 18.06.20 - 14:35
(63) Я был бы не против
    Структура = Объект["ИмяРеквизита1,ИмяРеквизита2,ИмяРеквизита3"]
   Волшебник
 
Модератор
65 - 18.06.20 - 14:36
(63) Можно было бы аккуратнее считывать тяжёлые реквизиты (строки неограниченной длины, ХранилищеЗначения) и табличные части. В остальном работает быстро.
   1Снеговик
 
66 - 18.06.20 - 14:37
Как это теперь нельзя использовать точку? Я что-то пропустил?
   Волшебник
 
Модератор
67 - 18.06.20 - 14:40
(66) >> Все мы знаем, что обращение через точку эту моветон
пишет нам сегодня зарегенный бот
   Serg_1960
 
68 - 18.06.20 - 16:26
PS: читать или нет ТЧ объекта при обращении "через точку" - это не вопрос. Как и предложение читать ТЧ позже при реальном обращении к ТЧ. Это не тема для обсуждения если вспомнить про многопользовательский режим работы и получение непротиворечивых данных. Если читать - то читать всё и сразу.
   ДенисЧ
 
69 - 18.06.20 - 16:30
(68) Можно просто накладывать блокировку...
   ptiz
 
70 - 18.06.20 - 16:49
(0) Как раз ОбщегоНазначение.ЗначениеРеквизитаОбъекта(Ссылка, "Рекв") - это костыльный костыль. Никакой читабельности.
   Ненавижу 1С
 
71 - 18.06.20 - 16:55
Все это ерунда
Надо встроенные в язык запросы и функциональные типы
   mistеr
 
72 - 18.06.20 - 17:07
(68) >Если читать - то читать всё и сразу.

А чего не всю базу сразу? "Непротиворечивость" нужно рассматривать в контексте.
   dezss
 
73 - 18.06.20 - 17:17
Вообще было бы логично для чтения всего объекта из базы использовать отдельный явный вызов, а через точку читать только конкретный реквизит, если мы весь объект не читали.
Что-то вроде
КонтрагентПрочитанный = КонтрагентСсылка.ПрочититьИзБазы();

З.Ы.: ну или ПрочититьИзБазыИменемНуралиева();
   RomanYS
 
74 - 18.06.20 - 17:52
(73)
>> через точку читать только конкретный реквизит
тогда станет (очень распространенными) граблями:
Рекв1 = Объект.Рекв1;
Рекв2 = Объект.Рекв2//повторный запрос к базе


>> использовать отдельный явный вызов
Их и сейчас есть: от ПолучитьОбъект() до Запрос("Выбрать * Из ... где ссылка = &ссылка")

Вопрос: зачем и чем это лучше текущей картины?
ИМХО здесь главный критерий логичности - соответствие документации, ну и вообще такое поведение (чтение целиком и кэширование) не выглядит абсолютным костылём.
   fisher
 
75 - 18.06.20 - 17:59
(74) Перевернем ситуацию.
Предположим, что "главный критерий логичности" соблюден. И в документации написано, что по "точке" выполняется неявное обращение к БД за этим конкретным реквизитом.
Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
И тут кто-то предлагает "а давайте по первому обращению через точку неявно вытягивать весь объект?". Как далеко его бы тут послали? Я думаю - очень далеко.
   dka80
 
76 - 18.06.20 - 18:00
(74) лучше уж повторный запрос, чем сразу тащить непонятно чего и в каком объеме. В оракле данные храняться не в строках, а в столбцах как раз исходя из того, что в большинстве случае данные требуются частично
   Cthulhu
 
77 - 18.06.20 - 18:00
ну сам код можно перед компиляцией препроцессировать неким оптимизатором. для одноточечной оптимизации - в принципе все не так уж и сложно (строится на кэш-структуре):
- отловить точки относительно объектов;
- собрать для таких объектов словари ("словари усечения" у trdm);
- для каждого из построенных соответствий объект-словарь препроцессировать код: перед первым использованием - присвоить по имени объекта структуру, в которую запросом (добавленным в тот же код или типа бсп-шного) - вытянуть только то, что упомянуто в словаре.
trdm что-то типа этого имел ввиду?..
ЗЫ: ну, или заморочившись правилами оптимизации и обратимостью - сам код в конфигураторе оптимизировать - отменить, не замахиваясь на требования доработки платформы...
   RomanYS
 
78 - 18.06.20 - 18:14
>>Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
Так же будет масса "специалистов" пишущих простыни "Рекв1 = Объект.Рекв1;...Рекв100500 = Объект.Рекв100500;" и удивляющихся что 1С тормозит.

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

(76) >> лучше уж повторный запрос
Не лучше. Если мы говорим про средний объект(без сотен реквизитов и огромных ТЧ), то пара-тройка запросов будет не оптимальней чтения объекта целиком.
   dmpl
 
79 - 18.06.20 - 19:27
(69) Угу, и получить тормоза на ожидании блокировки... типа, хочешь изменить объект... но низззя! потому что его кто-то прочитал, например, для отчета. И так пока или сборщик мусора не уничтожит все ссылки на этот объект, или программист явно не разблокирует объект.

(72) Непротиворечивость для объекта нужна гораздо чаще, чем для базы.
   dmpl
 
80 - 18.06.20 - 19:29
(73) Т.е. ты хочешь получить кучу трудноуловимых глюков, которые не сможешь продемонстрировать исполнителю? Глюки будут возникать, когда объект будет меняться другим пользователем пока ты его читаешь.
   MyNick
 
81 - 18.06.20 - 19:51
(0) потому что это удобно. При обращении через точку - в кэш вычитывается весь объект. Последующие обращения через точку к этому же объекту вызывают обращения к памяти, а не к БД.
   Cthulhu
 
82 - 18.06.20 - 19:58
(81): чот вас колбасит. субъективное "удобство" аргументируете совершенно не относящимся к удобству способу ресурсозатратной реализации метода... єто нихера не удобно - это вынуждено.
   vi0
 
83 - 18.06.20 - 20:01
(0) как то давно была большая дискуссия на эту тему на парнерском форуме, и завел ее, Тормозит, если я не ошибаюсь
в общем 1сники были не убедительны в дискуссии, как я помню
киньте сюда ту ссылку, кто найдет
   Злопчинский
 
84 - 18.06.20 - 20:14
(81) а если объект в базе поменялся, как кэш актуализируется при "повторном" обращении через точку?
   Провинциальный 1сник
 
85 - 18.06.20 - 20:32
По сути, чтение объекта целиком в кэш вместо реквизита, к которому обращаемся через точку - это вариант "упреждающего чтения (read ahead)" в райд-контроллерах. В подавляющем большинстве контроллеров есть возможность как включить эту возможность, так и отключить. А ещё, во многих реализациях есть "адаптивное упреждающее чтение", которое при чтении нескольких блоков подряд производит чтение еще нескольких после них. Что-то подобное можно было реализовать и в 1с. Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам  - в четвертый раз читаем весь объект в кэш.
   Cthulhu
 
86 - 18.06.20 - 20:39
(84): а никак. кстати, в семерке - точно так же. ожидать иного, кстати - глупо.
   Cthulhu
 
87 - 18.06.20 - 20:40
(85): ... или где-то вести статистику - и кэшировать те реквизиты, которые чаще всего юзаются...
   Wern
 
88 - 18.06.20 - 21:05
Если читать только один реквизит то может получится что читаешь контрагента, потом читаешь договор и между двумя чтениями кто то влезет и изменит объект. и получится что договор не соответствует контрагенту. А если читаем сразу весь объект такого никогда не случится. Объектный подход. Ты либо читаешь весь объект, либо ничего. У регистров сведений, например, нет объектов и обращение через точку не приводит к считыванию большого объема данных.
   RomanYS
 
89 - 18.06.20 - 21:14
(85) >> Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам  - в четвертый раз читаем весь объект в кэш.

В итоге четыре раза сходил в базу, а объект больше не понадобился. Бред же. Никакой логики.
Сейчас программист сам может решать когда и что читать и как это оптимизировать, а не рассчитывать на оптимизатор, который может не угадать.
   ptiz
 
90 - 18.06.20 - 21:20
(84) " Однако чтобы считывание происходило не при каждом обращении – данные объектов кэшируются системой. Если обращаться через ссылки к свойствам одного и того же объекта базы данных, то считывание данных будет происходить только при первом обращении, а так же после того как система выгрузит этот объект из кэша. Данные объекта удерживаются в кэше около 20 минут, но после интервала в 20 секунд при очередном обращении будет выполняться проверка того, что объект в базе данных не менялся, и, при необходимости, выполняется обновление данных в кэше. Если объект записывается в данной сессии, то он сразу обновляется в кэше. Также имеются ограничения на количество объектов хранимых в кэше. Следует заметить, что в рамках транзакции система использует отдельный кэш, поэтому обращение к данным объекта через ссылки в транзакциях гарантированно выдает актуальные данные. "
https://its.1c.ru/db/metod8dev#content:2700:hdoc
   dmpl
 
91 - 18.06.20 - 21:26
(89) Вообще да. Если что-то объемное и критичное к времени выполнения - обычно это делается одним запросом, и в выборке уже готовые данные, обращаться через точку просто нет необходимости. А там, где время не критично - можно и через точку, зачем код усложнять?
   Ёпрст
 
92 - 18.06.20 - 23:01
во-во.. и в тексте запроса еще отменить..пусть всё лепят ручками, через соединения.
   Cthulhu
 
93 - 18.06.20 - 23:25
(92): а вот хренасдва. по "ЗЫ" в (77) на коленке слепил скрипт для нотепад++ - работает, "одноточечная" оптимизация-откат кода.
   strange2007
 
94 - 19.06.20 - 04:21
(8) >> А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.
Не прокатит. Я уже пробовал. Как только начинаешь делать что-то сверхсерьёзное, так сразу закапываешься и славливаешь тормоза на всём. Не реально на ассемблере писать учётные системы.
   MyNick
 
95 - 19.06.20 - 05:04
(82) ну вообще-то в это реализация классического Model-View-Controller в 1с.
Используется повсеместно.
И только грамотным 1сникам это кажется непонятным расколбасом.
   strange2007
 
96 - 19.06.20 - 05:51
А я всегда через точку обращаюсь, что бы было видно от кого эта переменная. Знаю, что это плохо и вредно, но так удобнее)))))

А ещё локальные переменные объявляю вначале процедуры через Перем и вношу описание, для чего и от чего они. Тоже ересь полная, но так удобнее и красивее. Зато минимизируются "зависшие" переменные
   Провинциальный 1сник
 
97 - 19.06.20 - 05:58
(89) Опционально должно быть. Директива #КэшированиеОбъекта Адаптивное|Отключено|Полное в коде. А по умолчанию - отключено.
   Конструктор1С
 
98 - 19.06.20 - 07:58
Думаю, в принципе это ООП-стиль - сразу получать весь объект. В этих ихних ООП не делают отдельных объектов для получения 1-2-3 полей основного объекта. Сразу тащится весь объект и уже из него получаются нужные поля

ИНН = Контрагент.getИНН();
КПП = Контрагент.getКПП();
Адрес = Контрагент.getАдрес();

а сколько там полей внутри объекта Контрагент и сколько из них понадобится уже никого не парит
   MyNick
 
99 - 19.06.20 - 08:06
(99)  И какой в этом смысл? Вообще не пойму, чем вам помешало кэширование объекта в переменную?
   mistеr
 
100 - 19.06.20 - 08:41
(98) Давно ли ты заглядывал в "эти ихние ООПы"? Просветись про CQRS.
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
Компьютеры — прекрасное средство для решения проблем, которых до их появления не было.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.