В новой версии платформы «1С:Предприятие» доработан механизм расширений
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(15) да, принимаю ваше замечание.
Однако как мне видится, лучше бы под дополнительные реквизиты создавалась дополнительная таблица, в которой была бы колонка со ссылкой на сам объект и колонки доп.реквизитов. Однако это бы несколько снижало производительность запросов так как это еще одно соединение.
Однако как мне видится, лучше бы под дополнительные реквизиты создавалась дополнительная таблица, в которой была бы колонка со ссылкой на сам объект и колонки доп.реквизитов. Однако это бы несколько снижало производительность запросов так как это еще одно соединение.
О да, теперь заживем!
Интересное решение, что при расширении не создается новая таблица с ГУИДом и новыми колонками, а целая таблица переносится. Жесткая будет реструктуризация, если расширять или удалять расширение таблиц с тысячами элементов.
Интересное решение, что при расширении не создается новая таблица с ГУИДом и новыми колонками, а целая таблица переносится. Жесткая будет реструктуризация, если расширять или удалять расширение таблиц с тысячами элементов.
(23)Я хотел на мальдивы и всю жизнь пить коктейли глядя на бескрайнюю синюю гладь. А 1С извернулись и сделали возможность расширять функциональность конфигураций не снимая их с поддержки. Снова недоволен.
Можно и так написать. ООП и мальдивы с расширениями связывает только одно: они не имеют к ним никакого отношения.
Можно и так написать. ООП и мальдивы с расширениями связывает только одно: они не имеют к ним никакого отношения.
(30)
А вы не думаете, что создание расширения - это наследование, а изменение функций и типовых содытий в расширении - полиморфизм?
(23)
ИМХО ООП нафиг не нужно, какие проблемы с помощью него Вы будете решать?
1С и так заставляет мыслить разработчика терминами предметной области. Дополнительные абстракции тут не к чему.
А вы не думаете, что создание расширения - это наследование, а изменение функций и типовых содытий в расширении - полиморфизм?
(23)
ИМХО ООП нафиг не нужно, какие проблемы с помощью него Вы будете решать?
1С и так заставляет мыслить разработчика терминами предметной области. Дополнительные абстракции тут не к чему.
(32) Ну, пожалуй, это наследование. Только это какое-то уж такое, здоровенное такое наследование. Где в качестве родителя выступает вся конфигурация. Изменение функций и типовых событий - это скорее переопределение, а не полиморфизм. Впрочем, как раз и без полиморфизма-то можно и обойтись.
ИМХО: добавление в язык платформы объектных возможностей, как мне представляется, позволит справляться с растущей сложностью прикладных решений. Уже сейчас есть проблемы в этом направлении. Понятие класса, понятие какой-то группировки классов в пакеты (или иные кластеры), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
ИМХО: добавление в язык платформы объектных возможностей, как мне представляется, позволит справляться с растущей сложностью прикладных решений. Уже сейчас есть проблемы в этом направлении. Понятие класса, понятие какой-то группировки классов в пакеты (или иные кластеры), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
(33)
Но ведь есть Общие модули, модули менеджера, модули объекта. Этого вполне достаточно для уменьшения зависимостей.
Не хватает, возможно, закрытых переменных.
Но это решается, используя DTO. Т.е. мы переменные класса выделяем в структуру, а методы класса, сосредоточенные в общем модуле или модуле менеджера, производят изменения этой структуры.
Такой подход, например, в типовой обработке проведения в УТ11. Создаем структуру, где есть данные для проведения. При этом у нас есть методы с одинаковым названием для каждого документа, которые содержаться в модуле менеджера и возвращают набор записей. Они заполняют структуру, а потом наша "фабрика" записывает движения.
), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
Но ведь есть Общие модули, модули менеджера, модули объекта. Этого вполне достаточно для уменьшения зависимостей.
Не хватает, возможно, закрытых переменных.
Но это решается, используя DTO. Т.е. мы переменные класса выделяем в структуру, а методы класса, сосредоточенные в общем модуле или модуле менеджера, производят изменения этой структуры.
Такой подход, например, в типовой обработке проведения в УТ11. Создаем структуру, где есть данные для проведения. При этом у нас есть методы с одинаковым названием для каждого документа, которые содержаться в модуле менеджера и возвращают набор записей. Они заполняют структуру, а потом наша "фабрика" записывает движения.